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Executive Summary 

This report summarizes an investigation of the DAVE-ML markup language, performed at Johnson Space Center 
(JSC) during the 2010 fiscal year. The work focused on several areas: (1) Integration of DAVE-ML software with 
the JSC Trick simulation framework, (2) Analysis of DAVE-ML interpreter performance, (3) Investigation of 
some non-aerodynamic DAVE-ML models, and (4) Analysis of tire S-119 and DAVE-ML XML draft 
specifications. 

Software Integration. Our effort to integrate DAVE-ML into JSC simulation software involved two activities: 
integration and code generation. The integration activity focused on integrating the two available DAVE-ML 
interpreter systems (Janus and LaSRS++/DaveMlTranslator) into Trick. The code generation activity involved the 
development of an XML-to-C/C++ code generator to create compilable code from a DAVE-ML model. 

For both activities (integration and code generation), we focused primarily on an I1L-20 lifting body simulation, 
incorporating the I1L-20 DAVE-ML aerodynamic model with the Trick simulation framework and a JSC 
dynamics package (JEOD) to provide a planet model, coordinate systems, vehicle dynamics and a vehicle 
trajectory. We implemented a single "generic" software model that integrated our Trick-based simulations w ith 
cither the Janus or the LaSRS++ DAVE-ML interpreters. Details of this generic design arc provided in the report. 
We also implemented an XSLT-bascd XML-to-C/C++ code generator that allows the DAVE-ML model 
algorithms to be executed dir ectly rather than interpreted in the Janus or LaSRS++ DAVE-ML "virtual machines". 
We found this generated code useful as a baseline against w hich to compare the runtime performance of the 
interpreted approach. It could also be used to compare against a hand coded translation of a DAVE-ML transferred 
algorithm during development. 

Execution Time Study of DAVE-MI, Interpreters. Our performance analysis of DAVE-ML models involved 
the investigation of a Trick-based IIL20 auto-landing simulation integrated w ith ( 1) the Janus DAVE-ML 
interpreters, (2) the LaSRS++ DAVE-ML interpreter, (3) the C code auto-coded from our XML-to-C/C++ code 
generator, and (4) some pre-existing hand-coded HL-20 source code. In all four cases, the simulations generated 
the same trajectory. We found that interpreted DAVE-ML was of comparable speed to auto-goncratcd compiled C 
code and hand tuned code for the limited testing we performed. Detailed results arc available in tire report, 
including some of the w eaknesses of the method we used for performance analysis. 

Non-Aerodynamics Models Im plemented in DAVE-ML. In addition to our work with the HL-20 aerody namics 
model, we looked at tw o non-aerodynamic DAVE-ML models: (1) An HL-20 reaction control system (RCS) 
algorithm, and (2) A pneumatic tire force model. Our investigation of the RCS algorithm, in particular our 
succcssfiil representation of it in DAVE-ML and subsequent execution of the model using the Janus and LaSRS++ 
interpreters and our XML-to-C7C++ code generator, offers some evidence that models beyond the aerodynamics 
niche can indeed be represented through the current DAVE-ML specification. In particular, dynamic models with 
saved states can be created in DAVE-MI. 2.0 without direct support in the specification, by the caller providing 
work space for the states. 'This worked reasonably W'cll w hen aided by a convenient method of hooking together 
corresponding simulation and internal DAVE-ML interpreter variables. Our investigation of a pneumatic tire data 
compression model show ed that the self-documenting properties of DAVE-MI, can be used to record provenance, 
modification, and accuracy data for static data sets; sophisticated models can be created entirely in MathML 
vvitliout recourse to table look-ups; and that models can be created in a hierarchy where die outputs from one are 
then fed into the next in DAVE-ML 2.0, even though this feature is not supported directly in the specification. 
Further details arc available in the body of report. 

DAVE-ML Specification Comments/Suggestions. In the course of our investigations, we collected some 
observations about the DAVE-ML specification, in particular the XML DTD. These observations are primarily the 
result of (1) our code generation work and (2) a detailed look w r e took into tire DAVE-ML uncertainty element. 
Generally w e found that in a few places the DAVE-ML DTD is insufficiently precise to support automatic code 
generation (e.g., certain XML element attributes are optional leading to the possibility that a DAVE-ML compliant 
XML model might not allow code generation without some manual intervention). We also found that the 
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documentation of the uncertainty element in the Reference Manual could be improved, and we drafted a proposed 
replacement for the relevant section of the Reference Manual to fix some (but not all) of the weaknesses we found. 
Our detailed observations arc available in the body of the report 

Conclusions and Suggestions for Future work. We suggested several clarifications and changes to the 
DAVE-ML specification that are described in more detail later in this report, and summarized in the conclusions 
section. We feel these changes would improve the rigor and clarity of the specification, making it easier to develop 
inteipreters and code generators for DAVE-ML. and helping to transfer models without ambiguity. The feasibility 
of an XSLT based DAVE-ML to “C” code gener ation capability was demonstrated during this assessment 
Although incomplete, tire system prototyped during this project is useful now and shows considerable potential for 
future expansion. The utility of the DAVE-ML specification for use by non-aerodynamics models was shown by 
two test cases, that also investigated hierarchical models, a pseudo-dynamic model with saved states implemented 
via caller provided memory storage, and demonstrated two ways to use “macros” (essentially) to ease MathML 
authoring for complex algorithms. We suggested several areas where future work would be useful, fhese include 
further exploration of the S-l 19 and DAVE-ML specifications, continued development of tire XSLT code 
generator tow ard an operational capability, and testing of the DAVE-ML <uncertainty> element by exercising it to 
specify dispersion test cases for the Trick Monte-Carlo capability. 
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Acronyms 


AIAA 

American Institute of Aeronautics and Astronautics 

API 

Application Programming Interface 

DAVE-ML 

Dynamic Aerospace V ehicle Exchange Markup Language. 

DSTO 

Defense Science and Technology Organization (Australian Dept, of Defense) 

DTD 

Document Type Definition. 

FSME 

Flight Simulation Model Exchange program of the NESC 

GNC 

Guidance, Navigation and Control 

HAC 

Heading Alignment Cylinder (or Circle) 

JEOD2 

JSC Engineering Orbital Dynamics model set, version 2 

JSC 

NASA Johnson Space Center 

URC 

NASA Langley Research Center 

LaSRS-H- 

Langley Standard Real-Time Simulation in C++ 

MathML 

Mathematics Markup Language. 

NASA 

National Aeronautics and Space Administration 

NESC 

NASA Engineering Safety Center 

RCS 

Reaction Control System 

S-119 

Draft Specification: “Flight Dynamics Model Exchange Standard," 
BSR/AIAA S-l 19-200X 

Trick 

The Trick Simulation Environment 

UML 

Unified Modeling Language 

XML 

Extensible Markup Language 

XSLT 

Extensible Stylesheet Language Transformations 
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1.0 INTRODUCTION 


The goals of this project were to support the NASA Engineering Safety Center (NF.SC) in their efforts to study the 
American Institute of Aeronautics and Astronautics (AIAA) draft specification S-1 19 Flight Simulation Model 
Exchange (FSMF.). The work at NASA Johnson Space Center (JSC) was part of a multi-center effort to gain 
experience in integrating Dynamic Aerospace Vehicle Exchange - Markup language (DAVE-ML) models into 
the local simulation systems of each center in order to more efficiently transfer simulation models. 


2.0 SCOPE 

llic major tasks were to: 

• Review FSME project documents 

• Integrate DAVE-ML models into the local (in this case, NASA/JSC) simulation construction flow 

• Demonstrate the integration by using the HL20_aero.dml DAVE-ML file as the basis of an HL-20 landing 
simulation 

• Evaluate the S-1 19( 1) and DAVE-ML(2) draft specifications for their purpose 

• Provide feedback on the specifications 

• Make a recommendation with the other participating centers for the draft specification. 


3.0 METHODS 

Our basic strategy for integration of DAVE-ML into JSC simulation construction flow was to integrate use of 
simulation models, expressed in DAVE-ML format XML files, directly into common JSC simulation construction 
tool sets via example DAVE-ML interpreters. These included the Trick Simulation Environment and the JSC 
Engineering Orbital Dynamics (JEOD) model set. The two available DAVE-ML, interpreter systems were 
DaveMlTranslator(3) (NASALaRC) and Janus(4) (DSTO). 

As a second method of integration, we investigated the feasibility of generating C source code from DAVE-ML 
file algorithms via XSLT(5)(6) (Extensible Markup Language Transformations). Given the ubiquity of XSLT 
tools, if found to be feasible, this seemed like a widely applicable method of either directly integrating DAVE-ML 
models, or at least greatly easing the task of converting models from DAVE-ML to C. 

An alternative to this strategy would have been to build tools to convert DAVE-ML file models to local (Trick 
format) input files and code. One interesting lack in the Trick Simulation Environment, however, is a single 
preferred method of performing a table look up from data. This is typically left to the model builder. Given the 
preeminence of such structures in DAVE-ML and w ithout such a baseline code module to target converted input 
files tow ard, w e felt our time during this assessment was better spent pushing the eapabilities of the tw o provided 
DAVE-ML interpreter systems to their limits, and also to pursue code generation as better fitting into the usual 
flick usage patterns. (Trick simulations typically contain a strong element of code generation). 

Evaluation of the S-1 19 and DAVE-ML specifications ended up being concentrated on the DAVE-ML 
specification, through an extensive review and suggested re-drafting of the ' uneertainty> element, and 
DAVE-ML Document Type Definition (DTD) issues that cropped up during the XSLT based code generation 
work. 
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4.0 SOFTWARE INTEGRATION 


4.1 Integration of Two Provided DAVE-ML Interpreters with Trick and JEOD2 

Two existing DAVE-ML Interpreters provided through the FSMF, program by the DSTO and NASALaRC were 
integrated into the Trick Simulation Environment (Trick(7)) and the JSC Engineering Orbital Dynamics (JEOD 
version 2 (8)) model package in object oriented fashion. 

These two toolsets are in w idespread use at NASA/JSC and elsewhere for real-time simulation of vehicles and 
robotics. One of the major results of the JSC participation in the FSME program is the development of a 
framework to integrate DAVE-ML capability into these common simulation development toolsets via the 
DAVE-ML interpreters or a new code generation capability (described later). 

The new DAVE-ML capability was exercised primarily dirough construction of a Trick/JEOD2 based HL-20 
auto-landing simulation as specified in the FSMF. program. This new simulation featured runtime interpretation of 
a DAVE-ML aerodynamics model simulating the flight of the HI .-20 as a single rigid body from Mach 4 to 
touchdown. The HL-20 simulation is able to run in real-time or non-real-time modes, unpiloted. and lands under 
the control of an auto-coded auto-landing guidance, navigation and control (GN&C) algorithm provided by 
NASALaRC. 


Additional miscellaneous simulations were constructed using the same structure to exercise other DAVE-ML 
models for various purposes during the study and will be described later. 

Figure 1 shows tire layered hierarchy of simulation software modules used to construct the HI ,-20 auto-landing 
simulation, which was developed during this program. Each layer uses the capabilities provided by the layer 
below. The simulation is shown divided into four major layers, and data files: 


• Simulation Environment 

• User Models 

• DAVE-ML Interpreters 

• 3rd Party' Libraries 

• plus tire Data Files. 


These five areas are separated by dashed lines in Figure 1. The solid lines in the figure indicate software module 
interactions. The arrows show data flow for DAVE-ML file interpretation during runtime and also code generation 
of MatLab™ models to code. 
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Figure 1. Layered Software Structure 


Hie Trick Simulation Environment served as the base framework for the simulation, providing simulation 
executive functions, model organization, and code generation, as well as real-time capability and input, output, 
monitoring, and plotting facilities. 

'Fhe JEOD version 2 model package provided the bulk of the simulation models. These included time 
management, planet models and cphcmcridcs. environment, coordinate systems, vehicle dynamics and trajectory 
integration. The JEOD general models were customized for this application using the Trick code generation and 
input systems. JEOD provides the Default Aero class as a hook for further specialization by tiro user. DcfaullAero 
w as used as llic base class from which the JEOD adapter modules were derived to hook DAVE-ML aero models 
into the simulation. Two software adapter objects were constructed to integrate the two provided DAVE-ML 
interpreters into the simulation structure in an object oriented fashion for the purposes of this investigation. 

The two DAVE-ML interpreters formed the third layer of the simulation: 

• Janus(4) provided by the Australian Defence Science and Technology Organization (DSTO), and 

• DaveMlTranslalor(3), part of the LASRS++ simulation, provided by the NASA/Langley Research Center. 
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The ma jor third party libraries forming die bottom layer of die simulation are also indicated in the diagram. These 
included: 


LibXML2(9) 

A cross-pladorm XML library used by DaveMITranslator 

(In wide use as the XML provider for the Linux GNOME desktop) 

Xerces(lO) 

A cross-platform XML library used by Janus 

(In wide use as die XML provider for die Apache web sen'er) 

Qhull(ll) 

A Convex Hull library used by Janus for ungridded table look ups. 

(In wide use by: MatLab, GNU Octave, Madiematica. Google, etc.) 


Additionally, MatLab™/ Simulink™/ Real Time Workshop™, a visual modeling system with code generation 
capability, was used to view and generate C code for die IIL-20 Auto-landing guidance, navigation and controls 
(GNC) algorithms from Simulink™ files provided by NASALaRC. 

This structure allow s DAVE-ML models to be loaded as XML files into a Trick/JEOD based simulation during 
initialization, eidier as JEOD aerodynamic models or as general models; and interpreted during runtime via either 
of the two supported DAVE-ML interpreters. 'Hie interpreter module to be used may be selected for each model 
during initialization via Trick input processing. 

The circled numbers in die diagram indicate the source of existing and provided modules and files per the Legend. 
Ihe blue colored "Implemented" items were newly constructed during this program. These include die various 
adapter modules used to integrate DAVE-ML models into Trick and JEOD, the HL-20 reaction control system 
(RCS) algorithm implemented in DAVE-ML, and the "glue code" required to integrate the aulocoded GN&C 
algorithm into the simulation. 


A summary LML( 12) (Unified Modeling Language) class diagram showing the details of the softw are integration 
is shown in Figure 2. 
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\ 
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* copy Inputs!) 

# copyOutputs!) 
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DaveMITranslator 
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+ getVariabloPointeMname : string) : double* 


Janus 


Figure 2. Summary UML class diagram. 


This implementation uses several object oriented software "Design Patterns"! 13): 

• The "Strategy" design pattern is used to select amongst similar algorithms that all provide a consistent 
interface to the using software modules via C++ inheritance. 

• The "Factory" design pattern is used to simplify construction of objects of the selected type. 

• The "Adapter" design pattern is used to adapt the differing interfaces of DaveMITranslator and Janus into 
a single interface capable of operating both embedded interpreters at the minimal level required of the 
simulation. 

• The DaveMITranslator base class uses the "Template Method" pattern to access the underlying interpreter 
APIs in a generic way. 


Current DAVli-ML version 2.0 models can be summarized as multi-input multi-output functions with no internal 
slates. To use the models, the values of simulation input variables (e.g.: angle of attack) must be passed to the 
corresponding variables vvitliin tire D AVE-ML model. The values of the output variables of tire DAVE-ML model 
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must then be passed back to corresponding output variables owned by the simulation. This basic structure is shown 
in Figure 3. and a specific example for the HI ,-20 aero model in Figure 4. 


Sim 

Input 

Vars 


DAVE-ML 

Model 


Sim 

Output 

Vars 


Figure 3. Generic DAVE-ML model integration with sim 


sv_dyn daveml_aero angleOf Attack 

sv_dyn.daveml_aero.angleOfSideslip 

sv_dyn.daveml_aero.mach 

svdyn.davemlaero.rollBodyRate 

sv_dyn.daveml_aero.pitchBodyRate 

sv_dyn daveml_aero.yawBodyRate 

svdyn .daveml_aero.airspeed 

sv_dyn.daveml_aero.hrwy 

sv_dyn.daveml_aero.d_BF_UL 

sv dyn daveml_aero d_BF_UR 

sv_dyn.daveml_aero.d_BF_LL 

sv_dyn.daveml_aero.d_BF_LR 

sv_dyn.daveml_aero.d_WF_L 

sv_dyn.daveml_aero.d_WF_R 
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sv_dyn.daveml_aero.gear 
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-BETA 
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- DBFR 
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sv_dyn.daveml_aero.cd 
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sv_dyn.daveml_aero.ci 

sv_dyn.daveml_aero.cr 

sv_dyn.daveml_aero.cm 

sv_dyn.daveml_aero.cn 


Figure 4. HL-20 aerodynamic model integration with sim. 


Two capabilities of the implemented softw are are potentially of general interest. These include the: 

• TDM Map class, providing a way to read an XMI , file specifying a mapping betw een tile names of sim 
variables and corresponding DAVE-ML model variable names. 

• DataMapper class and sub-classes. This system provides a general interface to obtain a pointer' to a 
simulation variable. When integrating with Trick, the TrickDataMapper subclass uses the Trick API to 
provide this sendee. The TestDataMapper subclass simply allows unit test code to enter {name.pointer} 
pairs to hook the model up to test code without requiring the Trick systems. 

Both of these systems could be used or extended for use in other simulation environments. ITtese systems are 
discussed in individual sections further below. 

The DaveMIModel class senes to adapt the differing application programming interfaces (APIs) of 
DaveMITranslator and Janus to a single generalized interface. (Note: In doing so, the additional flexibility of Janus 
allowing calculation of less than the full set of outputs was suppressed.) 

Figure 5 shows the DaveMIModel interface in UML. Methods shown w ith a “+” are public, those with are 
private, and those in italics are pure abstract methods that are required to be implemented by all subclasses. 
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DaveMLModel 

+ factoryBuild(interpreterType : int. trick_to_daveml_map_path : string, daveml path : string) : DaveMlModel* 
+ init(dataMapperPtr : DataMapper*) 

+ update)) 

+ islnterpreter<) : bool 
+ getTypeO : int 
it copylnputsO 

# copyOutputsO 

it getDaveMIVariablePointerfromNamefname : const s td::string&) : double * 

# int erpre terLoa dAndC heckl da vemIFilePa th : const std::stringSi, performCheckCases : bool) 

# interpreterlnitializeO 
tt interpreterUpdateO 

# interpreterTerminatel) 

Figure 5 DaveMlModel Interface in I ‘MI,. 


Once during initialization processing, the static member function factoryBuild is called to create the selected type 
of DAVE-ML interpreter - DaveMITranslator or Janus - and to specify the file names of the DAVE-ML file 
defining the model and the TDMMap XML file specifying the conespondance between simulation and internal 
DAVE-ML model variable names. Tlie init() member function is then called once. (Optionally, for unit testing the 
overloaded init version that allows injecting tire DataMapper object may be called). Tlie init method then uses the 
names provided by the TDMMap system to set up a mapping between simulation variable pointers (provided by 
the DataMapper) and the internal DAVE-ML model variable pointers (provided by member function 
gelDaveMT V ariab lePoinlerl'romName). 

During simulation run-time, tlie DaveMlModel: :update method is called repeatedly to perform tlie following steps 
in turn: 

a) Copy values from the input simulation variables to the corresponding internal DAVE-ML model 
variables, using the pointers set up during initialization. 

b) Update tlie internal DAVE-ML Model. 

For the DaveMITranslator API, this is calling tlie update!) method. (Tlie bulk of tlie DaveMITranslator 
processing occurs here. This interpreter recalculates all of tlie output variables values using tlie values of 
the input variables in this one update call.) 

For the Janus API, this function is empty (no action - see below). 

c) Copy values from the internal DAVE-ML model variables to the corresponding simulation output variable 
pointers as setup during initialization. 

For the DaveMITranslator API. this is a data copy between pointers. 

For the Janus API, this step is where the hulk of its processing takes place. Tlie value of each output 
variable is requested in turn. If Janus determines that intermediate variables needed to determine this value 
are stale, they are recalculated. The returned result is then copied to the simulation variable pointer (Note 
that the Janus capability of only calculating some of the outputs is not used in this generalized access 
strategy.) 
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The generic interface provided by the DaveMIModel class was determined to be sufficient for access to the 
minimum features of both the DavcMITranslator and Janus interpreters for general DAVE -MI, models. This 
generic interface is shown in Table 1 below. Each subclass derived from DaveMIModel implements this interface. 
The suggested implementation of the update method is shown below the table. 


Table 1 Generic Interpreter Interface Methods 


Method 

Puipo.se 

void copylnputsO 

Copy input values from sim variables to internal DAVE-ML 
model variables 

void eopyOutpulsO 

Copy output values from internal DAVE-ML model variables 
to sim variables 

void interpreter! xiadAndrheck 

(const sld::slring& filePath, bool 

pcrformChcckC ascs ) 

Command interpreter to: 
load DAVE-ML file 

perform DAVE-ML check cases (optional) 

double* getDaveMIVariablePointerfromName 
(const std::string& name) 

Return pointer corresponding to internal DAVE-ML variable 
"name" 

void intcrpretcrlnitializcO 

Command interpreter to set input variables to default values 

void interpreterUpdate() 

Command interpreter to update using the current input values 
already set (by copylnputs) and to copyOutputs 

void intcrprctcrTcrminatcO 

Destroy the interpreter 

void updated 

"Template Method" design pattern: 
see below for implementation 


The "Template Method" DaveMIModel: :update() is a generic recipe that all sub-classes implementing different 
interpreters can use to update their models. It is built up primarily of calls to the other generic interface functions. 

In C++, this recipe is: 


void update ( ) 1 

if ( ! islnterpreter ( ) ) { 

// set zeros into all outputs if a working interpreter is not available 
... (implementation not shown here) 

) else ( 

copylnputs ( ) ; 


// update the model using the input values 
interpreterUpdate( ) ; 


copyOutputs ( ) ; 


1 

Two adapter classes were constructed: 


• DaveMIModel is used to wrap a general DAVE-ML model intended to be embedded in user model class 
source code. 


• DavcMlModelObjcct has a slightly different public interface making it more convenient to place a 
DAVE-ML model as a child of a top level simulation object of a Trick sim. 
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4.1.1 Lessons Learned 

We found it valuable to have both the Janus and DaveMITranslator interpreters available. Janus is the more 
capable, providing ungridded table capability via the QHULL library. The two interpreters use different 
underlying XML libraries, so if parser problems or capability gaps were to be found for one interpreter, the other 
can be tried. One may have a faster run time performance for a particular problem than the other. 

Execution speed using the interpreters was close to hand eoded performance for the models we investigated 
(within a factor of 4). Should the interpreted performance prove inadequate for some problem, C source code can 
be auto-generated from DAVE-ML files using XSLT with some hand coded finishing work, or the algorithm can 
be fully hand coded from the DAVE-ML definition. The DAVE-ML internal checkData available with each model 
was found to be particularly valuable while integrating each DAVE-ML model. 

4.2 Simulation Data Mapping, and Testing 

During the course of this project we developed a general DataMapper interface that was used to encapsulate the 
Trick Simulation Environment’s system for returning memory pointers from variable names. Ihe Trick system 
w as accessed through this general interface so that a test-specific sub-class could be easily substituted for it during 
unit testing. This allowed testing of the DAVE-ML models separate from the Trick environment. 

This system worked along with the TDM Map system (sec the next section). The DataMapper provided pointers 
from simulation variable names, while TDM Map provided the correspondence between simulation variable 
names and internal DAVE-ML model variables. These two capabilities allow'cd the DavcMIModcl class 
(discussed previously), to hook up DAVE-ML models to the simulation via an XML file in a general way useful 
for all models. 


4.3 TDM_Map: Trick to DAVE-ML Variable Name Mapping 

A TDM map class simply stores pairs of variable names. One name in a pair refers to a DAVE-ML, model 
variable, while the other refers to a Trick model variable. An instance of a TDM-map is constructed from an XML 
file like the following, by calling the method TDM make map( ) : 
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0?xml version="l .O’* encoding="IS0-8859-l "?> 

< I DOCTYPE tdmap ‘JY5TEM ~ tdmap. dtd"> 

<1 — Description: Example Trick/DAVEML Variable Name flap — > 


< tdmap vers i on= " 1 . 0 " > 

<inputs> 

<varpair> <dave_ 
<varpair> <dave_ 
<varpair> <dave. 
<varpair> <dave_ 
<varpair> <dave. 
<varpair> <davo. 
<varpair> <dave. 
<varpair> <dave_ 
<varpair> <dave_ 
<varpair> <dave. 
</inputs> 


var>vt</dave_var> <tr ick_var>^16,vtotal</trick_var> </varpair> 
alpha e.var> < trick f 16. alpha 

var>beta</dave_var> <trick_var>fl6.beta</trick_var> </varpair> 
var>p</dave_var> <trick_var>fl6,p</trick_var> </varpair> 
var>q</dave_var> <trick_var>fl6.q</trick_var> </varpair> 
var>r</davo var> <trick var >fl6 # r</trick_ var > </varpair> 
var>al</dave_var> >fl6.el</t.r ick_var> </varpair> 

var>ail</dave_var> <trick_var>-F16*ail</trick_var> </varpair> 
rdr fl6.rdr 

var>xcg</dave_var> <trick_va: f 16.xcg</trick_var> </varpair> 


<outputs> 

<varpair> 

<varpair> 

<varpair> 

<varpair> 

<varpair> 

<varpair> 

</outputs> 

< /tdmap > 


<dave_var>ex</dave_var> <trick_var>fl6.cx</tr ick_var> </varpair> 
<dave var>cy</dave_var> <trick_var>T16.cy</tr ick var> </varpair> 
< dave.var >cz < /dave.var > < tr i ck_var >f 16 . cz < / tr i ck_var > < /varpa i r > 
< dave_var >cl < /dave_ var > < tr i c k _ var >f 16 . cl < / 1 r i c k _ var > < /varpa i r > 
<dave_var>c*</dave_var> <tr i ck_ var >^16. c»</tr ick_var> </varpair> 
<dave_var >cn< /dave_var > < tr ick_var>fl6.cn</trick_var> </varpair> 


The following is an example usage of TDMmakemapO, a factory class of sorts, to create a TDMmap object: 
itinclude “TDM_inake_map.hh" 

// Load and process the DAVE-ML to Trick mapping file 
// and setup the mappings 

TDM_map* tdmap = NULL; 

tdmap = TDM_make_map(mapFilePath.c_str( ) ) ; 

if (tdmap != NULL) { 

int i; 

int n_inputs, n_outputs; 

const char* dvar; 
const char* tvar; 

n_inputs = tdmap- > Number Of Inputs( ) ; 
n_outputs = tdmap->NumberOfOutputs(); 

for (i=0; i<n_inputs; i++) { 

tdmap->getInputVarPair ( i, dvar, tvar); 

// save the name 

) 

for (i=0; i<n_outputs; i++) { 

tdmap->getOutputVarPair( i, dvar, tvar); 

// save the name 

} 

// done with the map 
delete tdmap; 
tdmap = NULL; 

} 

Figure 6 below shows the relationships of the components of a TDM map. Note that it closely matches the 
structure of the XML file. A TDM component corresponds to an XML element. The TDM map, 

TDM varpairlist and TDM varpair each correspond to elements of the XML file. 
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Figure 6. TDM_Map Softw are UML Class Diagram 
A UML sequence diagram of the interactions is show n in Figure 7. 

The purpose of TDM make map() is to parse the XML file and pass the root node of the parse tree to the 
TDM map constructor so it can walk the tree, creating a in memory representation of the same information. 


4.3.1 Lessons Learned 

The TDM Map system is independent of the simulation environment being used. It can provide XML file model 
hookup capability for any environment, as long as the variable names it correlates can be used by following 
software like our DataMappcr class to find pointers to sim variables given their names, and the DAVE-ML 
interpreters arc wrapped in a class with similar capabilities to DavcMIModcl such that the available interpreters) 
can return pointers to internal DAVE-ML model variables from input variable names in a common way. 
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Figure 7. TDM_Map Software UML Sequence Diagram 
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4.4 Autocoding DAVE-ML to C via XSLT 

4.4.1 Feasibility of Transforming a Legal DAVE-ML Model into Executable "C” Code. 

DAVE-ML is an XML markup language for describing vehicle models. 

DAVE-ML's grammar rules (syntax), which specify how elements can be legally ordered, are described by its 
DID. Hie semantics of a DAVE-ML model file are conveyed by the definitions of its language-specific elements 
and attributes (specified in tire DAVE-ML Referenced)) and of course by the user-specific choices of those 
elements and attributes, ordered according to the grammar rules. 

This investigation is an attempt to determine the extent to which the syntax and 
semantics of DAVE-ML sufficiently and unambiguously describe a model that can be 
transformed into executable "C" code. 

The XML elements defined by DAVE-ML organize a lot of information about a model, including its definition, 
configuration history, data references, authorship, uncertainty and check data, lire elements that we are concerned 
with in this particular exercise are those related to the definition of the executable model, in other words, those 
elements that would need to be translated into “C” to properly represent the model. Figure 8 shows these 
DAVE-ML elements and their dependencies. 



IrpKrf 


Figure 8. DAVEML Elements and Dependencies that are related to Code Generation 
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Scone Limitations ; 

Became wc have a limited amount of time, we'd like to concentrate on getting the most “bang for buck” with what 
time wc have, therefore: 

• Only "gridded" data will be supported. 

• Only enough of tire MathML(14) to transform the F-16 and 111,-20 aero models will be processed. 

Choice of XSI.T : 

Since DAVE-ML is an XML(15) based language, XSLT (Extensible Style-sheet Language for Transformations) is 
a natural means of transforming it. 

• XSI.T is widely used for transforming XML. 

• It is an official recommendation of the World Wide Web Consortium (W3C). 

• There arc many freely available XSLT processors. 

Working on Linux, we chose xsltproc, a tool in the GNOME XSI.T library, because of its common availability. 


4.4.2 Design - Mapping DAVE-ML Elements to “C” Code 

The following sections map DAVE-ML elements to corresponding “C” code. They refer often to XSLT code in 
Listing 1 - DMLtoC.xsl by line number. 

DAVE func Element 

We will assume that the DAVE func element maps to a executable “C” model, because of our boundless optimism 
and because otherwise we would be admitting failure before wc even got started. The general approach w ill be: 

Generate the follow ing in the following order: 


Line Number 

Purpose 

33..34 

Necessary include files. 

41..43 

Variable Definitions generated from variableDef elements. 

50.. 52 

Breakpoint Definitions generated from breakpointDef elemenLs. 

59. .67 

Interpolation Data generated from gricldectTableDef elements and function elements. 

70.. 

In a function called update( ), perform the following: 

78.. 80 

Variable Initialization also generated from variableDef elements. 

87.. 89 

Function calls generated from function elements 

96. .98 

Assignment statements generated from variableDef elements. 


(Line numbers refer to those in Listing 1 - DMLtoC.xsl) 
variableDef Element 

A variableDef clement maps to variable definition in “C”. The name of the “C” variable can be taken from the 
@varID attribute (line 121). The initializer for the “C” variable can betaken from the @initialValue attribute. The 
type specifier for the “C” variable definition can probably, safely be assumed to be double. 

double vt = 1.0; 

Rather than creating initializers in the declaration, we initialized the variables with assignment statements (lines 
78.. 80, 135). 
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calculation Elemenl 

A calculation element maps to the right side of an assignment statement, in which the “C” variable associated with 
the parent variableDef element, is assigned the value resulting from the evaluation of a “C” arithmetic expression, 
corresponding to the enclosed MathML expression (lines 346, 360). 

Example C assignment statement: 

cq2v = ( ebar * ( q / tvt ) ) ; 


The expression within a <math> element is defined recursively. An expression is defined as: 

<cn> element ( a number ) OR 

<ci> elemenl ( an identifier ) OR 

<apply> element, consisting of: 

an operator ( - plus-- 1 minus - 1 ' limes-- 1 ... ) AND 

an aggregation of expressions). 


expression 






<en> 

<ct> 

<apply> 

operator 

operands 



Figure 9. UML Diagram For MathML <math> Elements 

If the expression is a <cn> element, then we need to emit the corresponding number. 

If the expression is a <ci> element, then we need to emit the corresponding identifier. 

If the expression is an <apply> element, then we need to first identify the operator 
and then process the remaining “sibling” operands, based on the operator that we found. 

XSI.T supports recursive template calls, so the transformations of plus, minus, times and divide (sub)expressions 
was straight forward. The one problem we ran into was how to transform a piecewise element into an expression 
suitable for the right hand side of an assignment. Though we haven't yet had time to figure out how to do it, we still 
think it might be do-able; possibly by transformation of the piecew ise element into a function which is then called 
on the left hand side of an assignment. 

So that we didn’t run afoul of C’s oper ator precedence rules, we put parentheses around all of the sub-expressions 
generated from transformations of the : apply-- element. 

Whether or not all possible MathML expressions, that might legally appear in a calculation element, can be 
translated to a corresponding “C” expression, is still an open question. 

function F.lcmcnt 

A function element also maps to an assignment statement (line 184). In this assignment statement, the dependent 
variable, specified by the dependentVarRef element, is assigned the value returned by an interpolator function call. 
The interpolator function will take as its arguments: 

• References to the independent variable(s), specified by the independentVarRef element and 

• A reference to the interpolation data, associated with the functionDefn element. 
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dependent var = interpolation fn( interpolation data ref, 

independent_var_l, .. 

, independent_var_n); 

independentVarRef Element 

An independentVarRef element maps to a “C” variable reference (line 209), that is: its name, which will be the 
same as the @varID attribute of the corresponding variableDef clement. 

dependentVarRef Element 

An independentVarRef element likewise maps to a “C” variable reference whose name is the same as the @varID 
attribute of the corresponding variableDef element. Dependent variable references appear on the left side of the 
assignment from the interpolator function calls (line 186). 

functionDefn Element 

A functionDefn element would generally map to some data structure that would consolidate the data necessary to 
specify either a gridded or an un-gridded interpolator. The data structure would contain the follow ing information: 

gridded | ungridded 

depending on the above type, either 

the data structure that specifies a gridded interpolator 

the data structure that specifies an ungridded interpolator. 

Because of our initial decision to limit the scope to gridded interpolation, we don't need to create this consolidation 
structure. We only use the structure necessary for gridded data. 

griddedTable F.lcmcnt 

A griddedTable element maps to an instance of some structur ed data type that consolidates the data necessary' to 
specify a gridded interpolator. 

The data type would need to contain the following information: 

• An ordered collection of (size /reference) pairs, one for each breakpoint array associated with the gridded 
interpolator, 

• The size (cardinality) of tire above collection, 

• A reference to the data writhin which wc arc interpolating. 

A unique identity for an instance of this “consolidation” data structure is needed. It might conceivably be derived 
from the @name attribute of the griddedTable element A problem with this is that the (Hnarne attribute is not 
guaranteed ( by tire DTD) to exist, and it is not guaranteed to be unique. 

A workaround is that its identity' can be derived from our knowledge that a griddedTable element is only contained 
in a functionDefn element, which is only contained in a function element which contains one independentVarRef 
clement, which has a unique name. 

griddedTableDef Element 

A griddedTableDef ’element maps to an instance of a data structure containing exactly the same type of 
information as the griddedTable element (above). 

A unique identity for an instance of this “consolidation” data structure is also needed. A griddedTableDef may 
have an @gtID attribute, but it is not guaranteed to exist. It can't derive an identity' from its unique existence in a 
parent clement with a unique identity, because it can be a child of the root clement DA VEfunc. In this case a unique 
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identity can’t be derived from a parent element's identity as it was in the case of tire griddedTable element, because 
the parent element is the root clement. 


dataTable Element 

A dataTable element maps to an array of type double (line 326). The identity of the array is derived from the 
identity of the parent ''griddedTableDef' or <griddedTable>. 


double CX_table data_table[] = { 

”-. 099 , -. 081 , -. 081 , -. 063 , -. 025 , . 044 , . 097 ,. 113 , . 145 , . 167 , . 174 , . 166 , 
-. 048 , -. 038 , -. 040 , -. 021 , . 016 , . 083 ,. 127 , . 137 , . 162 , . 177 ,. 179 , . 167 , 
-. 022 , -. 020 , -. 021 , -. 004 , . 032 , . 094 , . 128 , . 130 , . 154 , . 161 , . 155 , . 138 , 
-. 040 , -. 038 , -. 039 , -. 025 , . 006 , . 062 , . 087 , . 085 , . 100 , . 110 ,. 104 , . 091 , 
-. 083 , -. 073 , -. 076 , -. 072 , -. 046 , . 012 , . 024 , . 025 , . 043 , . 053 , . 047, .040 


Workaround for the Gridded Table Identities: 

In lines 59 .. 67, interpolation data structures arc selected and transformed by processing both 
griddedTablcDcf elements (template name = interp data from gridded table) and function elements 
(template name = inter]) data from function) at the top level (to extract embedded griddedTablcDcf and 
GriddedTable elements). 

Tlic “interp data from gridded table” template takes an identity parameter (intcrpID). From this identity, 
identifiers for the components of the corresponding “C” structures are derived. 

Line 60, which processes top-level griddedTableDef elements, calls the “inter]) data from gridded table” 
template (line 227)using tire ri gtID as tire identity parameter to generate interpolation data structures. 

Line 66 calls tire “interp data from function” template (line 161) which in turn calls tire 

“interp data from gridded table” template using the dependent variable as the identity parameter for both 

embedded gridded T able and griddedTableDef elements. 


breakpointRef s Element 

A breakpointRefs element represents a collection of breakpoint references. It maps to two a nays (line 280). The 
first array is a list of pointer’s to breakpoint arrays. The second is an array of the sizes of each of tire array’s pointed 
to by tire first. Tire names of tire arrays arc derived from the identity of the parent of the <breakpointRefs> element. 


double* CXtable breakpointRefs [ ] = (DEI, ALPHA1); 

int CX_table breakpointSizes] ] = { 

(sizeof (DEI ) /sizeof (DEI [ 0 ] ) ) , 

( sizeof ( ALPHA1 ) /sizeof ( ALPHA1 [ 0 ] ) ) 
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bpRef Element 

A breakpoint reference is the value of the @bpID attribute of the bpRef element. 

griddedTableRef 

A griddedTableRef element maps to a “C” variable reference, i.e.. its name, which will be tire same as the @gtlD 
attribute of the corresponding gricldedTableDef element. 

breakpointDef Element 

A breakpointDef element maps to a “C” array of type double. The name of the array is the value of the @bpID 
attribute of the breakpointDef element. The contents of the array initializer are the values contained within the 
bpVals element. 

double ALPHA1 [ ] = {-10. , -5. ,0., 5. ,10. ,15. ,20. ,25. ,30. ,35. ,40. ,45.}; 


bpVals Element 

A bpVals element maps the numbers within the initializer for the array corresponding to the breakpointDef 
clement. 


4.4.3 Lessons Learned 

Because we were able to transform the I II ,-20 and F-16 DAVE-ML files to executable “C” models, it appeal's the 
development of a general process is very feasible. 

A gr iddedTableDef clement at the root level of a legal (according to the DTD) DAVE-ML file is not required 
to have an @gtID. This makes it impossible to guarantee that that file can be transfonned to “C”. In order to 
make that possible, a user would currently be required to manually verify that griddedTablesDefs did have gtIDs. 

Although we've only created transfonnations for a subset of Math MI , operators, and we’ve not yet determined 
how to transform piecewise elements, we do believe that there is likely a solution. 
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Listing 1 - DMLtoC.xsl 

2 DAVE-ML to "C" Language Translator 

3 

4 Development Task: NESC Flight Simulation Model Exchange 

5 Development Lead: E. Bruce Jackson (bruce. jackson6nasa.gov) 

6 Developer: John M. Penn ( John. m. penn6nasa.gov) (L3 Communications) 

7 Developing Organization: 

8 Simulation and Graphics Branch 

9 Software, Robotics and Simulation Division 

10 Engineering Directorate 

11 NASA Johnson Space Center 

12 

13 This transform is an artifact of a study. It was created to provide just enough 

14 functionality to transform the two DAVEML-file examples that we had and is NOT 

15 GUARANTEED to work for all possible DAVEML files that can be created. It is not 

16 a finished product, but it might be a useful start. John M. Penn 

17 == == = ==== === = = === == ============== = = == ==== = ========== = ==== = ======= == === 

18 $Id; DMLtoC.xsl 119 2010-09-28 14;30;23Z mjessick $ 

19 — > 

20 

21 <xsl :transforin version="l .0“ 

22 xm 1 ns :xsl= "http://www.w3.org/1999/XSL /Transform" 

23 

24 <xsl : output method="text"/> 

25 <xsl ; strip- space elements="»"/> 

26 

27 01— === ===== = =========== ====== ================== = == = 

28 Transform DAVE-ML to C. 

29 = == == === ==== === ===== === == ==== = === =, 

30 —> 

31 <xsl : template match="/DAVEf ur>c" > 

32 

33 <xsl:text ttinclude "mlinterp.h"&»xA; </xsl : text> 

34 <xsl:text>*include "math.h"&#xA; </xsl : text> 

35 

36 <xsl:text>&»xA;</xsl:text> 

37 xsl : tex t /• =========================== •/& RxA ; < /xs I : i 

38 <xsl:text>/* = VARIABLE DECLARATIONS = */& RxA ;< /xsl : text > 

39 xsl : text >/» =========== = = = === == ==== «/&RxA ; < /xs 1 : text 

40 

41 <xsl :for-each select="variableDef " > 

42 <xsl ; cal 1 -template narae= " var _dec 1 arat ion M /> 


43 </xsl:foi — each > 

44 

45 <xsl:text>&RxA;</xsl:text> 

46 xsl : text /* ========= = === ======================= */&RxA; /xsl : t< ■ I 

47 <xsl :text>/« = BREAKPOINT DECLARATIONS = «/&RxA; < /xsl : text > 

48 xsl : text /» ============= === === == === = ========= = */&»xA; xsl: text 

49 

50 <xsl:foi — each select="breakpointDef " > 


51 <xsl:call -template name="bp_declaration" /> 

52 </xsl:for-each> 

53 

54 <xsl :text>&RxA;</xsl :text> 

55 <xsl : text >/» ======================================= */&«xA ; </xsl : text > 

56 <xsl ; text >/■ = INTERPOLATION FUNCTION DATA = «/&#xA ; < /xsl : text > 

8 1 < xsl : text >/* ================================== */&»xA j . xsl : text 

58 

59 <xsl :for-each select="griddedT ableDef " > 

60 <xsl : call- tem() late name="interp_data_from_griddedTable"> 
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61 0xsl : with -par am name="interpID" select=“egtID"/> 

62 < /xsl: call -template > 

63 </xsl:for-each> 

64 

65 <xsl:for-©ach selects "function^ 

66 <xsl : cal 1 -template name=~interp_data_from_function"/> 

67 ■ xsl :for-each> 

68 

69 <xsl : text>&*xA ;</xsl : text > 

70 <xsl:text void updateO { NBltUNt) 

71 <xsl :text>&»xA;</xsl :text> 

72 

73 <xsl : text >&*xA;< /xsl :text> 


74 <xsl : text >/ * ============= = === = ======== = ===== ==== «/&*xA; < /xsl : text > 

75 xsl : text /• == VARIABLE: INITIALIZATION ==./*,«xA; xsl; text 

76 xsl: text /* = ======== ============= === ======== «/ftM I; xsl: text > 

77 

78 <xsl :for-each select=“variableOef " > 


79 <xsl :cal 1 -template r»ame="var_initialization" /> 


80 </xsl :for-each> 

81 

82 < xsl : tex t >&ixA;</xsl: text > 

xsl: text /• ============= ====== =========== ======= »/&«xA; xsl: text. 

84 <xsl : text /* = KJNCI10N CALLS == •/ft»xA; XSl*1 

85 xsl : text /* ====== ======= ======== ====== === == ======= «/&ixA; ' /xsl : text > 

86 

87 <xsl ;for-each select="fur»ction"> 


88 <xsl;call template nume="interp_call_from_function"/> 


89 </xsl :for-each> 

90 

91 <xsl : text >&«xA;</xsl : text > 

92 • xsl ; text /* ======================================= m/y.Ux A; xsl;text 

93 * xsl : text /* == CALCULATIONS ==./&« x a ; xsl:text 

94 xsl : text /« ===== = ============== == == = = = = = === === */&»xA; xsl : text 

95 


96 <xsl:for-each select="variableOef/calculation“> 

97 <xsl:cail- template name="var_calculation“ /> 

98 </xsl:for-each> 

99 

100 <xsl:text>&*xA; </xsl:text> 

101 <xsl : text >}< /xsl : text > 

102 < xsl : text >&HxA; < /xsl : text > 

103 

104 <xsl:text>int maindnt arge, char* argv[]> {</xsl:text> 

105 < xsl : text >&*xA ; < /xsl : text > 

106 <xsl:text update ( );< /xsl : text > 

107 <xsl : text>&«xA; </xsl : text> 

108 <xsl : text) return (0) ;</xsl : t©xt> 

109 <xsl : text >&»xA; < /xsl : text > 

110 <xsl : text >}< /xsl : text > 

111 <xsl :text>&«xA; </xsl : text> 

112 

113 </xsl : temp late > 

114 

115 

116 

117 <1— =========================================================== 

118 Convert a <variableOef> element to a "C" language variable declaration. 

119 ======rr===================== = == = == = ============ ==== ======== = = = ==== = = == 

120 — > 
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121 <xsl : template name= "var .declaration" match="var iableDef " > 

122 <xsl : text) double './xsl:text> 

123 <xsl :valuo-of select.= ~0varID*V> 

124 <xsl : text>;</xsl : text> 

125 <xsl:text> //</xsl : text> 

126 <xsl :value-of select = "0na«e'*/> 

127 <xsl :text>&*xA; </xsl : text> 

128 </xsl : tempi at© > 

129 

130 <1— m ============= = ======== == = == = = == = ==s=s= == s= m = ========================= s 

131 Generate variable initialization code for those variables that have initialValue 

132 attributes. 

134 — > 

135 <xsl : template name= “var_initialization" match=**variableDef "> 

136 xsl : if t.est.= “0initialValue“ 

137 <xsl :value-of select=“6varID"/> 

138 <xsl:text> = </xsl : text > 

139 <xsl : value-of select="einitialValue*/> 

140 <xsl;text>;&«xA;</xsl:text> 

141 </xsl : if > 

142 </xsl : tempi ate> 

143 

144 <1— ============ = ==== ============= ===== =============== == ===== == = ======== 

145 Convert a <breakpolntOef > element to a "C" language array of doubles. 

1 46 =T?TT=T=r=;=T=T= ^ ====== = === = == =========== ============ ================ === === = == = == === = = = 

147 — > 

148 <xsl : template name= "bp_declaration“ match="breakpointDef "> 

149 <xsl : text > double </xsl:text> 

150 < xs 1 : va 1 ue-of select = * , GbpID*V> 

151 <xsl:text>[] = {</xsl:text> 

152 <xsl :value-of select = “bpVal 3"/ > 

153 <xsl ;texl>};</xsl : text- 

154 <xsl:text>&»xA;</xsl:text> 

155 </xsl ; tempi ate> 

156 

157 <1— = === = = ==== === ======= ======= ============= ================ 

158 Extract interpolation data and generate corresponding “C“ data structures. 

159 = = = = = = = Si = = == ======== = ==i _- === 

160 — > 

161 <xsl:template name=“interp_data_from_function" select="function"> 

162 

163 <xsl : var iable name= "depVarld** select="dependentVarRef/QvarID*/> 

164 

165 <xsl :for-each select="functionDefn/griddedTableDef " > 

166 <xsl: call- template name="lnterp_data_from_griddedTable"> 

167 <xsl :with-param name="interpID“ select=~concat (SdepVar Id, ’ _interp‘ )“/> 

168 </xsl:call template} 

169 </xsl:for-each> 

170 

171 <xsl;foi — each selectss"functionDefn/gr iddedTal)le"> 

172 <xsl :call-template name=“interp .data, from.gr iddedTable”> 

173 <xsl : with -par am name=“ interpID" select="concat (SdepVarld, 1 _interp’ )"/> 

174 </xsl :cal 1-template 

175 </xsl : f or -each > 

176 

177 </xsl : template> 

178 

179 @ 
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181 Generate interpolator Function calls. 

182 ================= = ============ ========== = === ===== ============ = === = = = == === 

183 — > 

184 <xsl : template names" in terp_cal l_f rom_ function" selects="Function"> 

185 

186 <xsl :var iat>le names "depVarld" select="dependentVarRef /Qvar ID"/> 

187 

188 <xsl :value-of select="$depVarId“/> 

189 <xsl:text> * </xsl:text> 

190 

191 <xsl:foi — each select="functionDefn/griddedTable"> 

192 litmt ml_interp( x-.l : 

193 <xsl : text>&Hx26;</xsl : text> 

194 <xsl;value-of select="concat<$depVarId, *_interp' )"/> 

195 </xsl : for -each > 

196 

197 <xsl ;for-each select="functionDefn/griddedTableOef" 

198 <xsl : text; ml_interp( </xsl:text> 

199 <xsl : text>&*x26;</xsl : text> 

200 <xsl :value-of selects "concat ( SdepVar Id _interp' >*/> 

201 </xsl:for-each> 

202 

203 <xsl:Foi — each select="functionDefn/griddedTableRef " > 

204 <xsl;text ml_interp( </xsl;text 

205 <xsl: text>&»x26;</xsl: text> 

206 <xsl :value-of select="@gt ID"/ > 

207 </xsl:For-each> 

208 

209 <xsl;fo> — each selects** independent VarRef "• 

210 <xsl:text>, </xsl:text 

211 <xsl lvalue of select="0varID"/> 

212 </xsl: for -each/ 

213 <xsl:text> ); </xsl :text> 

214 <xsl jtext >&»xA; </xsl : text> 

215 

216 </xsl : template ■ 

217 

218 

220 Convert a <griddedTableDef> or a <griddedTable> to corresponding "C" data 

22 1 structures . 

222 

223 Parameter : 

224 interpID — Interpolator ID. 

225 = === = = == == = == = == = = =================== ==================== ========= ======= = 

226 — > 

227 <xsl : template namo="interp_data_from_griddodTable" 

228 se 1 ect=~gr i ddedT ab 1 eOef I gr i ddedT able" > 

229 

230 <xsl:param names" interpID" select=“F IXME"/> 

231 

232 <xsl :text>&*xA; </xsl : text> 

233 <xsl : text>/« INTERPOLATION DATA : </xsl:text> 

234 <xsl jvalue-of select="$interpID"/> 

235 <xsl:text> »/&ixA;&ixA; </xsl : text> 

236 

237 <xsl :for-each select="breakpointRefs“ > 

238 <xsl real 1-template name="gen_C_bpref_arrays**> 

239 <xsl ;with-param names" InterpID" selects "$interpID“/> 

240 0 </xslscall tempi ate > 
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241 </xsl:for-each> 

242 

243 <xsl :for-each select=’’dataTable“> 

244 <xsl : cal 1- template name="gen_C_data_table"> 

245 <xsl :with-param naroe=**interpID“ select=“$interpID"/> 

246 </xsl : call -template) 

247 </xsl jfor-each> 

248 

249 < xsl : text) MLInterp ) /xsl: text > 

250 <xsl : value-of select=’*$interpID"/> 

251 < xsl: text >» {&«xA;</xsl :text> 

252 <xsl:text> </xsl:text> 

253 <xsl :value-of select=“SinterpID‘V> 

254 <xsl:text) breakpointRef s,&*xA;< /xsl: text > 

255 <xsl:text> </xsl:text> 

256 <xsl :value-of select=“$interpID' , /> 

257 <xsl : text> data_table,&«xA;</xsl : text> 

258 <xsl:text> </xsl:text> 

259 <xsl : value-of select=’*$interpID"/> 

260 <xsl : text) breakpoints! zes, &HxA ; </xsl : text > 

261 <xsl:text> </xsl:text> 

262 <xsl ;text>(sizeof (</xsl : text> 

263 <xsl jvalue-of oolect=*‘$interpID'V> 

264 <xsl :text) breakpointSizesVsi zeof (</xsl :text 

265 <xsl :vaUie-of 8elect=**$interpID"/> 

266 <xsl :text) breakpointSlzes[0]))&txA; < /xsl :text 

267 <xsl : text > } ; &«xA ; < /xs 1 :text> 

268 

269 </xsl : template> 

270 

271 

272 <1— ======================== = === = = === == = ==== = === = ==================== = ========== 

273 Convert <breakpointRefs> element to an array of pointers to breakpoint arrays 

274 generated by the "bp_declaration" template above. 

275 

276 Parameter : 

277 interpID - Interpolator ID, 

278 = =================== == ==================== = ==== = ============== = ========== = 

279 — > 

280 < xsl : temp late name=“gen X_bpref _arrays** match=“breakpointRefs"> 

281 

282 <xsl:param names" interpID"/> 

283 

284 <xsl:text double* </xsl:text> 

285 <xsl: value-of select="$interpID"/> 

286 <xsl:text) breakpointRefsf 1 = {</xsl:text> 

287 

288 <xsl sfor-each select="child: : •"> 

289 <xsl : value-of select»"self : :bpRef/6bpID"/> 

290 <xsl:if tost="not (posit ion ( )=last ( ) )"> 

291 <xsl:text> f </xsl:text> 

292 </xsl:if > 

293 </xsl : for -each > 

294 < xsl :text> };</xsl : text > 

295 < xsl : tex t >&«xA ;< /xsl: text > 

296 

297 <xsl : text>int </xsl:text> 

298 <xsl : value-of select="$interpID"/> 

299 <xsl:text) breakpointSizes[] = {</xsl:text> 

300 [] <xsl : text>&*xA; </xsl : text> 
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301 

302 <xsl: for each select="child: : •"> 

303 <xsl;text> </xsl;text> 

304 <xsl : text/ (si zeof (</xsl : text> 

305 <xsl: value of select=**self : :bpRef/0bpID "/> 

306 <xsl ;text> )/sizeof ( :/xsl ; text 

307 <xsl :value-of select="self : :bpRef/6bpID "/> 

308 xsl : text [0])) xsl: text 

309 <xsl:if t es t= “not (posit ion ( )=last ( ) )"> 

310 <xsl:text>, </xsl:text> 

311 <xsl ; text>&«xA; </xsl ;text> 

312 </xsl:if > 

313 < /xsl: for -each > 

314 

315 <xsl:text>&»xA; </xsl:text> 

316 <xsl : text >};</xsl : text > 

317 <xsl :text>&*xA; </xsl :text> 

318 

319 </xsl: template/ 

320 

321 

322 < ! — =========================================================: 

323 The data table is part of the interpolation data. 

324 ================ ==== ============== ======= = ======= ======= =========== ========= = 

325 — > 

326 < xsl : template name="gen_C_data_table" match="dataTable“ > 

327 

328 <xsl:param name="interpID" select=TIXME“/> 

329 

330 <xsl : text: double </xsl:text> 

331 <xsl : value-of select="$interpID"/ > 

332 <xsl:toxt data_tablo[] - { XSlittKt 

333 <xsl :text>&»xA; </xsl :text> 

334 < xsl : value-of select="."/> 

335 <xsl :text/&NxA; </xsl : text> 

336 <xsl:text>};</xsl : text> 

337 <xsl : text>8r«xA; </xsl : text> 

338 

339 </xsl : template) 

340 

341 < I — ====== = === == == = ==^^^^= = ==== = ===== == ===^^— 

342 Generate an assignment statement from a <calculation> element and the 0varID 

343 attribute of it*s parent <var iableOef> element. 

344 === =========================================== = == === ========= ====== = 

345 — > 

346 <X3l rtemplate names "var .calculation** matchs**caiculation"> 

347 <xsl : value-of select=". ,/6varID*/> 

348 <xsl:text> « </xsl:text> 

349 <xsl : apply- templates 3elect=**math"/> 

350 <xsl ; text> ;&«xA;</xsl ;text> 

351 </xsl : template> 

352 

353 

354 <1— ========= ===== = ======= ===== = = = = == = ==== =========== = ============== 

355 MATHML 

356 == ==== = ====== = === = ======= ======== = == == = =============== ==== = == = = === 

357 — > 

358 

359 <! — Generate an C-language math expression from a <math> element. — > 

360 fcjxsl : template match=“math"> 
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361 <xsl rapply- templates select="apply"/> 

362 </xsl : temp late > 

363 

364 <1 — Generate an C-language math expression from an <apply> element 

365 (within a <math> element). — > 

366 <xsl : template match="apply“> 

367 <xsl : text >(</xsl: text 

368 <xsl : apply- templates select=“plus“/> 

369 <xsl :apply- templates select="mlnus"'> 

370 <xsl : apply- templates select= “times" O 

371 <xsl rapply-templates select="di vide“/> 

372 <xsl ; apply- templates selects "power “/> 

373 <xsl rapply- templates select=“abs“/’> 

374 <xsl rapply-templates select="piecewise"/> 

375 <xsl : text > )</xsl : text> 

376 </xsl : temp late > 

377 

378 < xs 1 : temp 1 ate match= "p i ecew i se " > 

379 <xsl;text> 0 /*FIXME: piecewise needs handcoding help. »/</xsl ; text > 

380 </xsl : template) 

381 

382 <xsl : template match="piece M > 

383 <xsl rfor-each selects “chi Id: : *"> 

384 

385 <xsl : if tests "not (positi on ()=first())"> 

386 <xsl rapply-templates select="self : :apply"/> 

387 <xsl rapply-templates select=“self r :cl "/> 

388 <xsl rapply-templates select="self : :cn"/> 

389 </xsl:if> 

390 

391 </xsl :for~each> 

392 </xsl r temp late > 

393 

394 <xsl : template match="otherwise“> 

395 </xsl r template> 

396 

397 <! — Generate an addition sub-expression from a <plus> element. — > 

398 <xsl : template match="plus" 

399 <xsl rfor-each select="fol lowing-sibl ing: ; •“> 

400 <xsl rapply-templates select="self : :apply“/> 

401 <xsl rapply-templates select="self : :ci"/> 

402 <xsl rapply-templates select="self r :cn"/> 

403 <xslr if tests "not (posit ion ( )=last( ))"> 

404 <xsl:text> + </xsl:text> 

405 </xsl:if> 

406 </xsl rfor-each > 

407 </xsl r template> 

408 

409 <1 — Generate a unary-minus sub-expression from a <minus> element. — > 

410 <xsl rtemplate matchs"mirvus“> 

411 <xsl rfor-each seloct="fol lowing-sibl ing: : •"> 

412 <xsl:text> - </xslrtext> 

413 <xsl rapply-templates select=“self : rapply"/) 

414 <xsl rapply-templates select="self : :ci“/> 

415 <xsl rapply-templates selects "self ; jcn"/> 

416 </xsl rfoi — each> 

417 </xsl rtemplate > 

418 

419 <! — Generate a multiplication sub-expression from a (times) element. — > 

420 Qxsl rtemplate match="times**> 
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421 (^csl : for -each select="fol lowing-sibl ing: : • "> 

422 <xsl : apply- templates selects “self : :apply*V> 

423 <xsl :appl y- templates select=“self : :ci "/> 

424 <xsl :appl y- templates selects "self ; :cn"/> 

425 <xsl:if test=“not(position( )=last())“> 

426 <xsl:text> • </xsl:text> 

427 </xsl:if> 

428 </xsl:for-e«ch> 

429 </xsl : temp late > 

430 

431 <1 — Generate a division sub-expression from a <divide> element. — > 

432 <xsl : temp late match="divide" 

433 <xsl ;for-each select="fol lowing-sibl ing: : »"> 

434 <xsl :appl y- templates select=“self : :apply"/> 

435 <xsl :app l y- templates select="self : :ci"/> 

436 <xsl :appl y- templates select=“self : ;cn“/> 

437 <xsl:if test="not (posit ion ( )=last( ) )"> 

438 <xsl:text> / </xsl:text> 

439 </xsl:if > 

440 </xsl :for-each> 

441 </xsl : template > 

442 

443 <1 — Generate a exponentiation sub-expression, implemented as a call 

444 to pou(), from a <pouer> element. — > 

445 <xsl : template match= "power "> 

446 <xsl:text pow( (/xsljtext) 

447 <xsl:foi — each select="fol lowing-sibl ing: : *"> 

448 <xsl : apply- templates select="self : ;apply"/> 

449 <xsl : apply- templates select="self : :ci "/> 

450 <xsl : apply- templates selects "self ; ;cn"/> 

451 <xsl:if test="not(posltion( )=last( ))"> 

452 xsl:text , Vxsl:text 

453 </xsl:if> 

454 </xsl:for-each. 

455 <xsl:t.ext>)</xsl:text> 

456 </xsl : temp late > 

457 

458 <! — Generate a absolute- value sub-expression, implemented as a call 

459 to absO from a <abs> element. — > 

460 <xsl : template matcl>="abs" 

461 <xsl :text>fabs(</xsl : text> 

462 <xsl;foi — each select="fol lowing-sibl ing: : •**> 

463 <xsl: apply templates select="self : :apply* , /> 

464 <xsl : apply- templates select="self s :ci"/> 

465 <xsl: apply- templates select="self : :cn"/> 

466 </xsl:foi — each! 

467 <xsl : text > )</xsl : text) 

468 </xsl : template) 

469 

470 <! — Generate a variable identifier from a <ci> element. — > 

471 <xsl ;t.emplate match="ci "> 

472 <xsl :value-of selects" . "/> 

473 </xsl : template) 

474 

475 <1 — Generate a floating point number from a <cn> element. — > 

476 <xsl : template match="cn"> 

477 <xsl : value-of selects". "/> 

478 </xsl : template) 

479 

480 </xsl : transform) 
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Listing 2 - mlinlerp.h 

1 ■ifndef ML 1NTERP_H 

2 nd«firw> Ml _ INTERP_H 

3 □ 

4 /• 

5 Development. Task: NESC Flight. Simulation Model Exchange 

6 Development Lead: Bruce E. Jackson Cbruce.Jackson6nasa.gov) 

7 Developer: John H. Penn ( John.rn.pennenasa.gov) (L3 Communications) 

8 

9 Developing Organization: 

10 Simulation and Graphics Branch 

11 Software, Robotics and Simulation Division 

12 Engineering Directorate 

13 NASO Johnson Space Center 

14 

15 $Id: mllnterp.h 100 2010-08-23 20:49:572 pern $ 

16 •/ 

17 

18 ■lfcief cplusplus 

19 extern “C" { 

20 Mendi f 

21 

22 typedef struct { 

23 double** bpRef; /■•< Array (of length n [below]]) of pointers to the breakpoint arrays.*/ 

24 double* data_table; /••< Interpolation data. •/ 

25 int* bpSize; /••< Array that specifics the size of each breakpoint array.*/ 

26 int n; /■■< Number of independent variables. Same as number of breakpoint arrays. */ 

27 } MLInterp; 

28 

29 /•• 

30 Multi-linear interpolation function. 

31 6param interp_obj - Interpolator object. 

32 0param pa rami - first independent variable/parameter. 

33 ©return - interpolated value. 

34 */ 

35 double ml.intcrpC MLInterp* intorp_obJ, double paroml , ... ); 

36 

37 »lfdef cpUisplun 

38 ) 

39 »endif 

40 «endlf 


4.5 HL-20 Auto-Landing Simulation 

The FSME program leveraged tlie existing DAVE-ML HL-20 aerodynamic model to practice transferring an 
extensive aerodynamic model between organizations and building a simulation from it. 

At NASA/JSC, we built up a new IIL-20 simulation using the Trick Simulation Environment and the JSC 
Engineering Orbital Dynamics (JEOD) models as a base. We extended JEOD's aerodynamic model hook and buill 
an object oriented class system for embedding four different selectable IIL-20 aero model implementations into 
the simulation. Along tire way, general methods of connecting internal DAVE-ML interpr eter variables to 
simulation variables were created. (Tire software integration was discussed in more detail in previous sections.) 

The new simulation results were reviewed against previously published results including: 

• Internal DAVE-ML checkData cases for tire IIL-20 aero model( 16)( 17), run through tire two interpreters, 

• Visual comparison with the step response plots reported in TM107580(16), 

• Visual comparison with the published trajectory of TM107580( 16). 

An example pitch-step response, comparing tire expected result as published in TM107580 to tire Trick simulation 
result Is shown in Figures 10 and 1 1. 
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Figure 10. HI.-20 Trick Sim, Pitch Pulse, Angle of Attack Trace 


HL-20 Dynamic Chock Caso Data Plots 911206 
Alt Pitch Stick Puls* at 300 KEAS, 10,000 ft 



Figure 11. TM 107580 Pitch Pulse, Angle of Attack Trace 


The trajectory comparing to the single case documented in TM 107580 was in rough agreement although the 
precision of the visual comparison was not high, due to the lack of digital comparison profiles. 

Several representative trajectory profile plots for approach along a 155 degree heading with a left turn around the 
Heading Alignment Cylinder (IIAC) to a final approach along a 0 degree heading are shown in Figure 12 and 13 
below. Note that this was the trajectory used for the Execution Time Study reported in tire next section. 
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Figure 12. HL-20 Auto-Landing Trajectory, Overhead Map 
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The GN&C algorithm as auto-coded and integrated into this simulation may be operating differently in the 
supersonic regime than the legacy TM107580 algorithm( 16). The ability to hold the commanded angle-of-attack 
seems reduced. This may point to a lingering algorithm re-hosting or auto-coding issue. Since the use of the 
simulation was primarily to integrate and evaluate the DAVE -MI. based aerodynamic model, rather than the 
auto-coded GN&C algorithm, fiirthcr investigation of this anomaly was suspended in favor of other tasks. 

It is interesting to note the high degr ee of uniformity among the trajectories from all four versions of the 
DAVE-ML HL-20 aero model. As seen in Table 2, lire touchdown points after 400 seconds of flight are identical 
for the three models interpreting or generated from the same DAVE-ML Trie, and different from the legacy hand 
coded C model by less than 2 feet. 

Table 2. Touchdown Conditions Compared For The Four HL-20 Aero Model Versions 


Aero Model 

Runway Relative Downtrack, ft 

Runway Relative Crosstrack, ft 

DaveMlTranslator 

420.723151 

-20.102880 

Janus 

420.723151 

-20. 102880 

XSLT Generated C code 

420.723151 

-20.102880 

Legacy Hand Coded C 

418.834007 

-20.133210 
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5.0 EXECUTION TIME STUDY OF DAVE-ML INTERPRETERS 

This task compared the execution time of four versions of the HL-20 aerodynamic model using a single 
auto-landing scenario as the duty cycle. The execution time taken to process a single update of the HL-20 
aerodynamic model was measured for the following versions of the model: 

• DaveMITranslator DAVE-ML interpreter. 

• Janus DAVE-ML interpreter, 

• XSLT generated from DAVE-ML, with hand finishing, 

• Legacy hand coded C version of the model. 

lire intent of this study was to measure the execution time of the different model implementations as embedded 
within a representative Trick JKOD installation, over a single representative trajectory for a large DAVE-ML 
model, and a single computer system. (Additional constraints are discussed below under "Weaknesses".) 

Note that although the IIL-20 aero model has many table look-ups, they' all use the simplest linear interpolation 
technique. While it can be considered "large", it likely falls short of "complex" relative to the full spectrum of 
possible DAVE-ML models. 


5.1 Trick Job Timing System 

The Trick Simulation Environment job timing system was used to collect the data. Ibis system uses the Linux 
clock_gett ime ( CLOCK_REALT XME ) function and provides results to microsecond resolution. This function 
uses tire Intel hardware “RDTSC time stamp counter” for tire test computer used. 

'Hie Trick job that includes the JEOD aerodrag function was measured. A small amount of administrative code 
calculating angle of attack and sideslip from body velocity inputs, and copying input values into the DAVE-ML 
model, and copying output values out of the DAVE-ML model, was included in each measurement. Note that this 
is several levels above the interpreter. It was assumed that the cost of these overhead routines is small in 
comparison to the time required to perform the DAVE-ML model calculations in tire interpreter, and would be 
approximately the same for each of the four tested versions of the IIL-20 aero model. 

Because tire Trick job timing system does not allow' the collection of data for "derivative" type job calls (w hich is 
the job class appropriate for aero model jobs), an additional job was programmed to occur outside the numerical 
integration collection of aerodynamic forces. Because these additional timing jobs are interspersed with tire normal 
derivative jobs (in this case, 4 calls per simulation dynamics frame for the Runge-Kutta fourth order integration 
technique), the effect of the derivative jobs on the measurements is unclear. It is conceivable that optimizations 
inside the interpreters could allow the measured jobs to perform better than the derivative jobs w hich could not be 
measured using the standard Trick system. 

5.2 Test Computer and Operating System Specifications 

The single test computer and operating system used for the testing had the following specifications: 

Specifications: 2 processor Intel Core™2 6600 CPU at 2.4 GHz, cache size: 4096 KB 

Operating system: CentOS 5 (kernel 2.6. 1 8-8. 1 .8.el5) for x86 64 

This computer was procured circa late 2007 to early 2008. 
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5.3 Compiler and Compilation Flags 

This section documents the build and compilation flags used for each library. We used the highest level of 
optimization recommended for each library’ in their included documentation, installation and build files. 

Janus: g++ -D_REENTRANT -I.. -I.. /Janus -fPIC -06 -Wall -march-x86-64 -funroll-loops 

-f inline-functions -c Janus. epp 

qliull: CC0PTS1 - -02 -ansi -f no-str ict-aliasing 

Xerces, version 2.8.0: as of version 2.8.0, the xcrccs makefile uses the -02 optimization level for GNU/Linux with the 
gcc/g++ compilers 

DavcM ITranslator -03 -funroll-loops -f ini ine-functions 

Simulation: -03 -funrol 1- loops -f inline-functions (affects JEOD models and sim models) 

5.4 Miscellaneous Settings 

Trick flags locking the CPU of the main simulation process to the second core and locking the process into 
memory were used. Core 0 was specified for a secondary Trick process (the Variable Server). Using these settings 
resulted in fewer outliers in the timing data. 

5.5 Weaknesses of the Test Method 

Several weaknesses arc inherent in the method used to measure the duration of each model update. 

These included tire following: 

• The measured job includes some (assumed constant) overhead needed to hook tire model to the simulation: 
o Calculation of angle of attack and sideslip inputs 

o Input hookups copying data from simulation variables to Interpreter variables 
o Output hookups copying data from interpreter to simulation variables 

• Only a single computer, architecture, compiler, operating system, and test case duty cycle were measured. 

• T he duty cycle selected, w hile the largest available w ithin the capabilities of all the methods tested, does 
not include use of the most complicated and time consuming elements (e.g., ungridded tables). Of the four 
methods, only Janus has ungridded table capability. 

• This restricts the test case to only the simpler constructs, severely biasing the results. 

5.6 Timing Results 

Figure 14 shows the raw per call processing duration results of the timing study between the four versions of tire 
HL-20 aero model over the 400 seconds of the simulated Hi ,-20 Auto-Landing trajectory. 
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Figure 14. CPU Time per Call, HL-20 Aero Model 


Only the XSI.T generated code shows any marked difference in the times per call over the trajectory'. The more 
polished algorithms show flat profiles throughout the trajectory. The reason for the jump in the XSI.T call duration 
at 105 seconds is unknown. It doesn’t seem to correlate with any event of importance, except perhaps crossing 
under Mach 2.(The jump occurs well before the start of turning around the Heading Alignment Cylinder.) It was 
originally theorized that the increased CPU time in this region was due to not-optimizing the search for the table 
look-up step in the indqiendent variable which was naively repeated from the first breakpoint for each table (e.g.: 
19.1 times per call for Mach). However, an experimental version of the simple recursive linear interpolator, which 
retained and re-used the solution of the most recent lookup, only improved the times for the XSLT gener ated 
model by around 2 microseconds all across the trajectory without changing the shape of the profile. Since 
performing an optimization study wasn't the point of the XSLT code generation feasibility exercise, further study 
of this interesting characteristic was not performed. 


Table 3 shows a summary of the data, with overall representative time values chosen by eye. 


fable 3. CPU Time per Call Summary, HL-20 Aero Model 


Aero Model 

CPU Time Per C all, micro-secs 

Janus 

73 

DaveMlTranslator 

34.5 

XSLT Generated C code 

22.5 - 28 

Legacy Hand Coded C 

18 
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5.7 Interpretation of the Results 

The CPU times required to proeess this fairly large aero model (240 one and two dimensional table look ups) in 
interpreted DAVE-ML, auto-generated C/C++ code from DAVE-ML, and in hand coded C code, were seen to be 
fast (under 100 microseconds), and similar (within a factor of 4) for the single test computer, operating system, and 
other simplistic conditions of this test. 

Due to the weaknesses already described in the limited testing performed, no further general conclusions should be 
drawn from these results. 

We feel it was valuable to have more than one interpreter available, and the prototype XSLT code generator w as 
also quite useful to have. Overall, these methods provided a spectrum of relatively quick and simple ways to 
implement a DAVE-ML transferred model into a simulation facility while providing performance reasonably 
close to hand coded algorithms. Even should real-time requirements require a customized hand coded version of a 
transferred model to be constructed from the DAVE-ML data, interpreted and XSLT code generated versions of 
the algorithm can be used to provide valuable independent comparison checks on the resulting hand coded 
algorithm. 


6.0 NON-AERODYNAMICS MODELS IMPLEMENTED IN DAVE-ML 

Two non-aerodynamie DAVE-ML models with various special features were constructed to exercise DAVE-ML 
outside this sphere. These models are described in the following sections. 

6.1 HL-20 RCS Algorithm 

The III.-20RCS control algorithm described by Po\vell( 1 8) was implemented in DAVE -MI. to investigate several 
interesting features of this model: 

• A “pseudo-dynamic” model with 24 saved states implemented via caller storage 

• Use of an XSLT script to expand “macros” collecting common sub-objects, easing MathMI . authoring ; 

o Lead and lag compensator digital filters: .compensator^ element 

o Relay blocks: <relay> element 
o Limiter block: <limiter> element 


The DAVE-ML implementation of the Pow ell RCS algorithm (see Figure 15) follows closely tire MatLab™ 
Simulink™ implementation provided by NASA/LaRC. 
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Mach > 3.5 



q < 50 psf 

Figure 15. HI.-20 RCS Algorithm of PoweII(18) 


The algorithm sub-objects mentioned above were implemented as “macros” allow ing expansion to DAVE-ML 2.0 
markup. The macros were placed in <variablcDcf > elements as children of ''calculation > blocks. It seemed 
reasonable that future DAVE-ML additions would allow any such new element types to be siblings of 
<calculation> blocks, allowing their use in variable definitions. 

Several different future forms of the compensator blocks were envisioned, e.g., S-domain and /.-domain 
coefficients, etc. Since DAVE-ML 2.0 compatibility was important during this investigation, the /-domain form 
was chosen, sidestepping the issue of providing a menu of different discretization methods. (When directly 
implementing the / domain transfer function form, only one discretization method needed to be implemented.) 


The macro concept allowed the blocks to be coded in a new format but implemented in DAVE-ML 2.0 compliant 
XML for use with current interpreters alter expanding the macro using XSLT. (See next section.) 


6.1.1 Ad hoc "Macro'' Substitutions via XSLT 

Implementation of this model benefited from the idea of extending DAVE-ML 2.0 through using special “macro” 
elements implementing algorithm sub-objects similar to MatLab™ Simulink™ “Blocks”. Future DAVE-ML 
versions might include specific elements for these or similar objects, using them directly. Here, XSLT was used to 
expand the macros to DAVE-ML 2.0 compliant foim (using Math ML elements) to allow the use of current 
DAVE-ML interpreters until such time. 
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Example limiter block logic expressed in C/C++ 

II limiter element performs a two-sided limiting operation 
if (input > highLimitValue) I 
output = highLimitValue; 

| else { 

if (input < loLimitValue) ( 
output = loLimitValue; 

) else ( 

output = input; 

) 

1 


This element requires no saved states. 


Example <limiter> macro element 

dimiter inputID="limiterRollInput" loLimxtValue“"“5.0" hiLimitValue="5 . 0” /> 


Example digital compensator block logic as difference equation 
A difference equation form of the digital compensator is: 

Y, = N 0 X,+ D, yj.j 


Where: 

Y output signal 
X = input signal 

N = digital transfer function numerator coefficients 
D - digital transfer function denominator coefficients 

This element requires two saved states: X i _ 1 and Y i _ 1 . 


Example <compensatorZ> macro element 

<compensatorZ input ID="compRoll Input" 

pr e v I npu t ID- "p rev_compRo 111 npu t_i npu t " 
prevOutputID="prev_compRollOutput_input" 
numz0="1.0" numzl=”-0. 9091" denzl="-0. 9394” /> 


This compensator implements a digital filter with the corresponding S-domain transfer function: 

with the digital filter coefficients calculated via the “zero order hold” discretization method for a time step of 
0.03125 seconds (32 Hz.). 


Example relay block logic expressed in C/C++ 

II relay element performs an input/output switch mapping with hysteresis: 
if (prevOutput > loSwitchValue) ( 

II was on 

if (input < loSwitchValue) ( 
output - loOutputValue; 
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) else | 

output - highOutputValue; 


) else { 

// was off 

if (input > highSwitchValue) ( 
output - highOutputValue; 

} else ( 

output - loOutputValue; 


I 

This element requires one saved state (prcvOutput). 


Example <relay> macro element 

<relay inputID-"relayRollInput" prevOutputID-"prev relayRollAOutput input” 

loSwitchValue="0 .5" hiSwitchValue="l . 0” 
loOutputValue-"0.0" hiOutputVa lue-”2 . 0” /> 


Example XSLT script to expand the < relay > element 1 relay.xsl 

<?xml version»"l .0" standalone- "no"?> 

<xsl : stylesheet version "1.0" xmlns: xsl-"http: //www.w3.org/1999/XSL/Transform"> 
<xsl: output method="xml" encoding=”iso-8859-l" indent="yes" /> 


<xsl: template name=”relay_block"> 

<xsl :comment> — — — Sit; relaySgt; element: 

inputID="<xsl: value-of select="@inputID"/>" 
prevOutputID**"<xsl : value-of select-"@prevOutputID"/>" 
loSwitchValue="<xsl: value-of select="@loSwitchValue"/>" 
hiSwitchValue="<xsl: value-of select="@hiSwitchValue"/>” 
loOutputValue="<xsl: value-of select="@loOutputValue"/>” 
hiOutputValue=”<xsl: value-of select="@hiOutputValue"/>” 
was expanded to: 

< / xs 1 : comment> 

<calculation> 

<math> 

<apply> 

<piecewise> 

<piece> 

<apply> 

<piecewise> 

<piece> 

tcnxxsl : value-of select-"@loOutputValue”/x/cn> 
<apply> 

<lt/> 

<ci><xsl: value-of select="@inputID"/X/ci> 
<cnXxsl: value-of select="81oSwitchValue”/X/cn> 
</apply> 

</piece> 

<otherwise> 

<cnXxsl: value-of select="@hiOutputValue"/X/cn> 
</otherwise> 

</piecewise> 

</apply> 
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<apply> 

<gt/> 

<ci><xsl: value-of select-"@prevOutputID"/X/ci> 

<cn><xsl : value-of select-"@loSwitchValue”/X/ cn> 

</apply> 

</piece> 

<otherwise> 

<apply> 

<piecewise> 

<piece> 

<cnXxsl : value-of select— "@hiOutputValue"/X/cn> 
<apply> 

<gt/> 

<ciXxsl : value-of select-"@inputID"/x/ci> 
<cnXxsl: value-of select="@hiSwitchValue”/X/cn> 
</apply> 

</piece> 

<otherwise> 

<cnXxsl: value-of select="@loOutputValue"/X/cn> 
</otherwise> 

</piecewise> 

</apply> 

</otherwise> 

</piecewise> 

</apply> 

</math> 

</calculation> 

<xsl :coroment> — — — — - end of expanded Sit; relaysgt; element </xsl;comment> 

</xsl:template> 

</xsl :stylesheet> 


Example Expanded DA VE-ML 2.0 Compliant <relay> Block 

Example excerpt showing a sample D AVF.-MI . variableDef (variable definition) element featuring an expanded 
relay macro in 1) AVF.-MI, 2.0 compliant XML: 

<variableDef name-"relayRollA" varID="relayRollA" units^"nd" initialValue~”0. 0”> 
<description>Roll relay A</description> 

<1 — --------- <relay> element: 

inputID="relayRoll Input" 

p r e vOu tpu tID-"prev_relayRol 1 AOu tpu t_i npu t " 
loSwitchValue="0.5" 
hiSwitchValue-”l . 0" 
loOutputValue-"0. 0" 
hiOutputValue-”2. 0” 
was expanded to: 

— XcalculationXmathXapplyXpiecewiseXpieceXapplyXpiecewiseXpieceXcn>0. 0</cn 
Xapplyxlt/Xci>relayRol llnput</cixcn>0. 5</cnx/applyx/pieceXotherwiseXcn>2.0< 
/ cnX/otherwiseX/piecewiseX/applyXapplyXgt/Xci>prev_xelayRollA0utput_input</ci 
><cn>0. 5</cnX/applyx/pieceXotherwiseXapplyxpiecewiseXpieceXcn>2. 0</cnXapply 
Xgt/Xci>relayRollInput</ciXcn>l . 0</cnX/applyX/pieceXotherwiseXcn>0. 0</cnX/ o 
therwiseX/piecewiseX/applyX/otherwiseX/piecewiseX/applyX/mathX/calculationX 
! — ========= end of expanded <relay> element — > 

</ variableDef > 
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Here, the MathML was simply expanded to one very long unreadable source line, since the purpose of the macro 
was to abstract and encapsulate this MathML construct (Minor additions to the XSLT script could be made to 
format this in h urn a ti -tea da b I ecd i tab lc form, if desired.) 


6.1.2 Test Method 

The HL-20 RCS algorithm was tested using a rigid body simulation featuring the DAVE-ML HL-20 aero model at 
low dynamic pressure (where the RCS jets can override the natural aerodynamic stability of the vehicle). The RCS 
thruster model used for the HL-20 was given in Reference (18) and repeated in Table 4 below. 

Table 4. HL-20 RCS Thruster Model 


Axis 

Moment (per thruster) 

Number of Thrusters 

Roll 

100 ft-lbf 

2 or 4 

Pitch 

333 ft-lbf 

2 or 4 

Yaw 

333 ft-lbf 

1, 2 or 3 


The HL-20 rigid body mass model (also from( 18)1) is repeated in Table 5. 


Table 5. HL-20 Entry Rigid Body Mass Model 


Axis 

Inertia 

Roll 

7512 slug-ft 2 

Pitch 

33594 slug-tY 

Yaw 

35644 siug-ff 


Mass 


19.100 pounds 


An artificial test state was constructed that reduced the dynamic pressure by a factor of 1.000. The state was 
otherwise correctly represented as 100,000 feet altitude and Mach 4. This adjustment was required because the 
DAVE-ML HL-20 aero models' range of validity extends from Mach 0.0 to only Mach 4. well below the Mach 
number where the low dynamic pressure region of RCS utility is usually encountered. 


6.1.3 Results 

The attitude performance of the algorithm in angle of attack and roll was tested using a scries of ramp inputs, as 
shown in Figures 16. and 17. Figure 18 shows the profile of body rates resulting from thruster firings over the same 
lime period. Because the algorithm was designed to maintain zero sideslip angle, no ramp command in yaw was 
used. How ever, yaw firings were required as seen in Figure 18 to maintain low sideslip during the eombined pileh 
and roll maneuver of the test. 
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HL-20 RCS in DAVE-ML 



Time, sec 

Figure 16. DAVE-ML IIL-20 RCS Algorithm Test Results: Angle of Attack 
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HL-20 RCS in DAVE-ML 



Time, sec 

Figure 17. DAVE-ML HL-20 RCS Algorithm Test Results: Roll Angle 
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HL-20 RCS in DAVE-ML 



Time, sec 

Figure 18. DAVE-ML I1L-20 RCS Algorithm l est Results: Body Rates 


6.1.4 Lessons Learned 

Pseudo-dynamic models were constructed under the existing DAVE-ML 2.0 D ID by using the caller to store what 
would be internal variables in a postulated future dynamic DAVE-ML. For now, the caller sends the states in as 
additional inputs, accepts them back as model outputs, and re-routes the values back into the input storage for tire 
next call. Using the TDM Map system (discussed above in the Software Section) to hook the DAVE-ML models 
to the Trick simulation, we were able to use the same simulation-side variables hooked to both the DAVE-ML 
input and output variables, so no explicit copying from model output to input was required between calls. This 
made the system very convenient to use. The caller essentially just provides a work array of the proper size for the 
saved slates and prepares the lDM Map XML file indicating the hookup of each work array clement to each 
DAVE-ML internal variable representing the dynamic states for both input and output. 

“Macros” expanded via a capable scripting language such as XSLT can be used to considerably simplify the 
authoring of complex MathML constructions. This allows the model author to make useful ad hoc “additions” to 
DAVE-ML and then generate DAVE-ML 2.0 compliant markup on-the-ily via XSLT for use with existing 
interpreters and DTD. If future DAVE-ML versions implement similar blocks, the implementation will likely be 
much closer to the macro element form than to the DAVE-ML 2.0 MathML based expansions, so using the macro 
form seems likely to ease any future conversion task. 
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6.2 Pneumatic Tire Data Compression Model 

The Pneumatic Tire Data Compression Model is a multi-input / multi-output set of three hierarchical DAVE-ML 
model files that coordinate to calculate the lateral forces on a tire from a set of experimental coefficients and tire 
current simulation states of a tire (normal force Fn, slip angle Alpha, and inclination angle Gamma). A high lev el 
diagram mapping the hierarchy is shown in Figure 19. 



Fy - lateral force component 


Figure 19. Tire Data Compression Model Set 


This model set features ; 

• A zero input / multiple output model 

• Hierarchical model sets where the outputs from one model are used as inputs to the next 

• An “equation heavy” model: no table look ups, just equations implemented in MathML 

• Use of a script to expand “macros” collecting common terms, easing MathML authoring. 

A Data Compression Model, as used in the modeling of pneumatic tires for automobiles, uses a single curve fit of 
complex shape that can be adjusted through a set of experimentally derived and curve fit coefficients to generate 
lire force results over a wide range of several important input state parameter values( 19). In this case, the curve fit 
is the “Magic Tire Formula” developed by Pacejka, as normalized by Woods(20). 

The Pacejka coefficients comprising the tire lateral force model are stored in a zero input / multiple output 
DAVE-ML file named lircDcmParam_latcral_paccjka.dml. DAVE-ML is used here for its self documentation 
features. Unfortunately, some portions of the DAVE-ML 2.0 specification preclude the use of zero input models. 
(The checkData element, if present, requires at least one input variable as the checklnputs element requires at least 
one signal element.) A workaround to use this type of model with existing DAVE-ML 2.0 compliant interpreters 
is simply to provide a single unused dummy input. This output only model can be run once only, with the outputs 
input to the next model. 
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The second model, tireDemParam lateral paecjka to woods.dml, converts the coefficients from Pacejka to 
Woods format. Woods dev eloped a useful normalization of the Pacejka model resulting in a different coefficient 
set that can be used in place of the standard Pacejka coefficients, with coefficients calculable from the Pacejka 
coefficients, lliis middle model can also be run once only. It takes Pacejka format coefficients as input with the 
output being the set of Woods format coefficients needed for the run-time stage. The DAVE-ML checkData 
feature is used to check the conversion using a comprehensive set of internal test case data reported by Woods. 

The DAVE-ML tire data compression model file tireDataCompression.dml makes heavy use of DAVE-ML's 
ability to implement algorithms through embedded MathML elements. The model contains no table look ups. only 
MathML equations. It calculates the output lateral force as complex functions of the coefficients and varying input 
slates: 


tire lateral force f ( slipAngle, normall'orce, inclination, coefficients ) 

Example output from the model is shown in Figure 20. The figure compares the output lateral force for several 
normal force load levels over a range of slip angles. The variation of the ratio of lateral force to maximum lateral 
force and the slip angle for peak force both vary smoothly under control of the model. The effect of the asphericity 
modeled in the example tire model coefficients provided by Woods (20) is evident as the friction coefficients cross 
zero at a small positive slip angle rather than zero. The small but non-zero offset forces programmed into the model 
also cause the friction coefficients to exceed the expected zero noimal force maximum at low normal force levels. 

The slip angle for peak friction coefficient for these tire model parameters becomes smaller as the load increases. 
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Tire Data Compression Model Results at Varying Loads 
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Figure 20. Tire Data Compression Model Example Output 


6.2.1 Ad hoc "Macro" Substitutions via Script 

Implementation of this model benefited from the concept of extending DAVE-ML 2.0 through the use of special 
“macro” elements similar to those used in the I II ,-20 RCS algorithm. The Woods normalized form of the Pacejka 
Magic Tire Formula makes repeated use of Linear Degradation and Quadratic Degradation constructs which 
proved straight forward to abstract out as macros. (This is the reason this form of the tire model was used.) 
However, for this model, XSLT was not used to expand the macros to DAVE-ML 2.0 compliant form as was done 
for the I II ,-20 RCS model. Instead, the object oriented high level (scripting) language Ruby (21 ) was used to 
expand the macros into DAVE-ML 2.0 compliant markup. 

Several restrictions to the format of the macros were imposed to enable use of an extremely simple parsing system 
to detect and expand the macro: 

• Attributes all present 

• Attributes in the expected order 

• Entire macro element on a single line 

• No other elements allowed on tire macro line 

'fhis allow ed the parsing of the macro and attributes to be performed entirely within regular expression queries as 
the input file was processed line-by-line, greatly simplifying the script. 
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Example common Quadratic Degradation term in equation form: 


1 - 0.1 



Macro source form of the Quadratic Degradation term: 

<quadraticDegradation constValue-"l . 0" gainValue-"-o. 1" numID“"gamma" denID-"gamma_y_mu"/> 

Script output cxccrpt of the DAVE -MI, 2.0 compliant form of the Quadratic Degradation after expansion: 

<! — ======= &lt; quadraticDegradation&gt; element: 

constValue “ 1.0 
gainValue = -0.1 
numID = gamma 
denID = gamma_y_mu 
was expanded to: — > 

<apply> 

<plus/> 

<cn>l . 0</cn> 

<apply> 

<times/> 

<cn>-0. l</cn> 

<apply> 

<power/> 

<apply> 

<divide/> 

<ci>gamma</ci> 

<ci>gamma_y_mu</ci> 

</apply> 

<cn>2</cn> 

</apply> 

</apply> 

</apply> 

<! — --------- end of expanded Slt;quadraticDegradationigt; element — > 


6.2.2 Lessons Learned 

Macros expanded via a capable scripting language using a simple parsing strategy can be used to considerably 
simplify the authoring of complex Math ML, constructions where repeated portions can be collected into macros. 
This provides a second technique alongside XSLT for expanding on-thc-fly ad hoc extensions to the DAVE-ML 
specification. 

Use of DAVE-ML for self-documenting data fries is impeded by the DTD restrictions against no input models. 
Although a trivial workaround is available, the D AVE-ML specification could be modified to allow these sorts of 
models without employing the workaround of using a dummy input variable. 
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7.0 DAVE-ML SPECIFICATION COMMENTS/SUGGESTIONS 

7.1 Uncertainty Element 

As part of our investigation of DAVE-ML, we studied the uncertainty XML element in the DAVE-ML 
specification. As a result of this study, we ( 1 ) collected some observations on the element itself and (2) wrote a 
proposed replacement for the section of the DAVE-ML Reference Manual that addresses uncertainty. 

A draft of our proposed section to the Reference Manual is included in the appendix. It probably w arrants some 
follow-up conversations w ilh the community. Indeed there are places in our draft where we call out issues that we 
believe w arrant further clarification. 

Our collected observations arc briefly summarized below. 

The bounds attribute. 

The current DAVE-ML DTD does not adequately constrain the bounds attribute in the several places where it 
may be used in the model XML. For example, when the uncert ainty element is applied to a single data value, 
then only one numerical bound is meaningful for normally distr ibuted uncertainties; but when the element is 
applied to a data tabic, there must be as many bounds as there arc data values in the table. The DTD could be 
redesigned so that XML validity would help ensure that the correct number of bounds values arc specified in the 
model. Also, the discussion of the bounds attribute in the reference manual is incomplete, accidentally omitting 
the discussion of bounds in the context of data tables. At tire very least, the DTD should enforce a single bound 
when the uncertainty clement is applied to a single value for normally distributed data. 

The effect attribute. 

It is our understanding that the absolut e value of the effect attribute is only applicable to uniformly 
distributed random data. Yet the current XML design allows it for normally distributed data as well. Thus a 
DAVE-ML model might validate (in the sense of XML "validation") yet not make any sense. The design of the 
DAVE-ML XML could avoid this if the effect attribute were moved "down" in the XML from the 
uncertainty element to tire normal PDF and uniformPDF elements. We suggest that this be done and that 
the DID only allow the absolute value for the effect attribute when that attribute occurs in the uniformPDF 
element. 

Specification semantics. 

In the course of our work with the uncertainty element, we struggled to understand how its use in a 
DAVE-ML file is supposed to be interpreted — what use cases it is intended to support. Although the intended use 
of the element on input data is easy to imagine (e.g., support Monte Carlo analysis), tire intended use of the element 
applied to internal and especially to output data is unclear. In some cases, these intended uses can be clarified by 
additional discussion in tire reference manual, but in some cases the standard does not specify unambiguous 
direction to simulation dev elopers on how to interpret tire uncertainty element. 

A data interchange standard may seek to solve three different kinds of problems: (1) making tire data readable by 
all parties (i.e., avoiding the problems implicit in proprietary file formats), (2) labeling tire various data items so in 
addition to being able to read the file, consumers can unambiguously identify which data item is meant to serve 
what role in the model, and (3) defining the semantics of the data so that not only are all data items readable and 
unambiguously identified, but the consumer know s how to use them without consulting the producer of the data. 
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Simple ASCII comma separated value (CSV) files provide an example of a solution to problem #1. The data arc 
readable by virtue of the fact that the data arc in an ASCII format and are delimited by a well-defined character. 
However a simple CSV file docs not specify which columns have what meaning. 

XML fdes can solve problem #1 as well as problem #2. Not only are the data readable, but they are (in most cases) 
unambiguously identified. 

We feel that there are some applications of the DAVE-ML uncertai nty element where the intended use is not 
currently specified by the standard and hence cannot possibly be implemented by generic simulation frameworks. 
For example, what does it mean for the statistics of an output Asia value to be specified in a model? How should a 
DAVE-ML-compliant simulation framework process such elements? It is entirely possible that there are good 
answers to tins problem, in which case this is just a matter of expanding the Reference Manual to clarify the 
intended interpretations. But if there is not universally agreed upon intended use for such cases, then the 
DAVE-ML community in general and the Reference Manual in particular should explicitly acknowledge that there 
are situations where a valid DAVE-ML model cannot be properly processed by a consumer until the engineers on 
the consuming side have consulted with the engineers on tire producing side. It is our understanding that the 
motivation behind the DAVE-ML model exchange standard was to avoid the need for such consultations. 
Therefore we feel that the DAVE-ML community should discuss the intended semantics of the uncertainty 
element in more detail before encoding it in the standard. 


7.1.1 Suggestions 

Based on our study of the DAVE-ML model of uncertainty, we have the following suggestions. Some of these 
relate to the XML syntax (i.e., the DTD) and some relate to the DAVE-ML Language Manual. 

• effect attribute 

- effect=“absolute” only applies to uniform distributions 

- suggestion: move this attribute from the uncertainty element one level down to tire normalPDF 
and uniformPDF elements, and don't allow effect “absolute” in normalPDF. 

• percentage vs. multiplicative effects 

- effect - “percentage” and effect _ “absolute” are different ways of saying the exact same tiring 
(except for a factor of 100). This needlessly complicates the standard. 

- suggestion: choose one and eliminate the other. 

• bounds element 

- the DID allows any number of bounds elements even in cases w here only one or two are allowed. 

- suggestion: change the DTD to precisely constrain the number of oceurances of the attribute in the 
1-occurancc case for normal distributions, the 2-occurancc case for uniform distributions and the 
N-occurancc case for data tables. 

• randomizing table data 

— There is no explicit guidance given to tool developers on how uncertain data points inside data 
tables should be interpolated. Should the interval boundaries be interpolated first and than a 
random value generated based on the uncertainty specification? Or should the interval boundaries 
be randomized according to the uncertainty specification and then interpolated. 

- suggestion: add explicit language clarifying the intent in the Reference Manual. 

• upper /lower uniform bounds in a data table 

— How should uniform distribution uppcr/low'cr bounds be encoded in a data tabic? For a table with 
N entiies, there should be 2N bounds (an upper and lower bound for each table entry'). The 
documentation in the DTD is incorrect for this case. It says that the table dimensions must match. 

- suggestion: Fix the documentation in the DTD. Clarify this point in the Reference Manual. 
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• nominal values 

— The documentation in the DTD for uniformPDF incorrectly says that the nominal value is given 
elsewhere in the parent XML element. This is true for tables but not true in general. For example, 
if the signal in question is an input or output, the nominal value is not specified in the XML file at 
all but rather determined during simulation execution. 

— suggestion: Fix the documentation in the DTD. 

• symmetric attribute 

— 'Die Reference Manual refers to a symmetric attribute of the uniformPDF element. This is 
evidently an artifact of a previous version of the DTD, as the current D I D has no such attribute. 

— suggestion: Update the Reference Manual. 

• comma separated data tables 

— The DTD is unable to constrain the contents of a data tabic to be comma delimited numerical 
values. This is a fiindamcntal limitation in DTDs. XML Schema would allow the content to be 
constrained according to a regular expression, and XML Schema is widely used in the XML 
community with significant tools support available. 

— suggestion: Move the XML specification from a DID to XML Schema. 

• correlation-related attributes 

— The attributes correlates With and correlation (in the normalPDF element) should be mutually 
exclusive. Furthermore, there is no DTD-enforccd constraint that both attributes be used correctly 
together (i.c., that the correlates With attribute designates a signal with a corresponding correlation 
attribute). 

— suggestion: Make these child elements instead of attributes. Use XML Schema to enforce mutual 
exclusivity. If possible use XML schema constraints to insist that an element referred to by 
correlates With actually does have a correlation. 

• correlation in data tables 

— It appears that the correlates With and correlation attributes may only be used in “scalar” signals 
(not in data tables). 

— suggestion: If this is true, mention this in the Reference Manual. If it is not true, include an 
example of how to use correlation with data tables. 

7.2 GriddedTableDef Element 

A griddcdTablcDcf clement at the root level of a legal (according to the DTD) DAVE-ML file is not required to 
have a @gtID. This makes it impossible to guarantee that that file can be transformed to “C”. In order to make 
that possible, a user would currently be required to manually verify that GriddedTablesDefs did have gtlDs. 


7.3 CheckData Element 

The current DAVE-ML 20 DTD does not allow zero input (or output only) models. These can be useful to take 
advantage of DAVE-ML’s self documenting elements for static data files for "Initialization Load" (I-Load) type 
data, lbe checkData/slaticShot/ehecklnputs hierarchy of elements requires at least one input signal definition, 
once the chcckData clement is present. Removing this restriction w'ould allow zero input output-only models 
without use of the workaround of using a dummy input currently required by the DAVE-ML 2.0 DTD. 
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8.0 CONCLUSIONS 


Several eommenls and suggestions were developed eonceming the DAVE-ML speeifieation included within the 
S-l 19 Specification: 


• Use of DAVE-ML for self-documenting data files is impeded by the DTD restrictions against no input 
models (chcckData hierarchy). Suggest removing DAVE-ML DTD restrictions against no input models. 

• Suggest requiring gtID attributes for griddedTableDef elements 

• Suggest revising the uncertai nty element specification for greater clarity. 

See the Appendix for suggested revisions, with comments describing areas where further review' is suggested 

“Macro” elements expanded via a capable scripting language can be used now' to considerably simplify' the 
authoring of complex MatliML constructions, and possibly ease conversion to future DAVE-ML versions that 
implement similar features directly. XSLT or high level scripting languages can be used to transform the output to 
current DAVE-ML 2.0 compliant form. 

General, reusable methods of hooking simulation variables to interpreted DAVE-ML model input and output 
variables can be created to specify the corresponding variable names conveniently via an input file. 

Pseudo-dynamic models can be constructed now under the existing DAVE-ML 2.0 DTD by using a caller 
provided work array as additional model inputs and outputs holding what would be internal variables in a 
postulated fiiturc dynamic DAVE-ML. A sim-variablc-to-DAVF.-ML-modcl-variablc hookup system, similar to 
the described TDM Map system, can do this transparently to the user by hooking the model outputs back into the 
inputs by specify ing the hookups via an input file that calls out the same sim variables for both input and output. 

Reasonably efficient C language source code can be automatically generated from DAVE-ML via XSLT, at least 
for the simpler constructs. Although incomplete, the system prototyped during this project is useful now r and shows 
considerable potential. 

We feel it w'as valuable to have more than one interpreter available, and tine prototype XSLT code generator w'as 
also quite useful to have. Overall, these methods provided a spectrum of relatively quick and simple ways to 
implement a DAVE-ML transferred model into a simulation facility while providing performance reasonably 
close to hand coded algorithms. Even should real-time requirements require a customized hand coded version of a 
transferred model to be constructed from the DAVE-ML data, interpreted and XSLT code generated versions of 
the algorithm can be used to provide valuable independent checks on tire resulting hand coded algorithm. 


9.0 FUTURE WORK 


We have identified several potential follow-on w ork topics. These are: 

• Further review of tire S-l 19/DAVE-ML specifications 

• Exercise an expected revision greatly expanding the HI.-20 aero model 
o Even larger model 

o Possibly exercising a wider subset of DAVE-ML features 
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• C ontinuc development of the XSLT DAVE -ML to C code generator 

o Increase its coverage of DAVE-ML constructs, 
o Increase robustness for production work 

o Low barrier-to-entry code getieration from DAVE-ML may assist adoption of the standard 

• Integrate DAVE-ML model uncertainty into the Trick Simulation Environment 
o Exercise with Monte-Carlo test cases. 
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APPENDIX A Draft DAVE-ML Uncertainty Reference 

It is our feeling that a more extensive discussion of the uncertainty element in the DAVE-ML Language 
Reference would help clarify its intended use and thus help software developers write interoperable DAVE-ML 
processing code. Ibis appendix is a draft of a proposed replacement for Section 6.4 (Statistics) section of the 
language reference, which we propose be renamed “Uncertainty”. It is undoubtedly incomplete but nevertheless 
captures our thoughts on what kind of discussion is warranted. 

In some places we have inserted “Author’s comments” where our understanding of tire proposer! XML syntax is 
incomplete. Additionally, please note that the section numbers in this appendix do not pertain to this document - 
they are actually the relevant section numbers from the DAVE-ML Language Reference. 

6.4 Uncertainty 

6.4.1 Introduction 

6.4.1. 1 Motivation 

DAVE-ML, supports the specification of statistical uncertainty' using the uncertainty clement. Its purpose is to 
allow models to characterize model uncertainty in two primary' use cases. 

Use Case I. Support Monte-Carlo simulation by allowing statistical variation of parameter values. DAVE-ML 
supports specification of tire uncertainty associated with constant parameters in addition to tire nominal value of 
the parameter itself. Titus DAVE-ML compliant simulations may run multiple versions of a particular scenario, 
each with different parameter values within the statistical bounds specified by the associated uncertainty 
clement associated with each parameter. 

Use Case 2. Support Monte-Carlo simulation by allowing statistical variation of table lookup values. DAVE-ML 
supports this use case with the specification of uncertainties of dependent values w hose nominal values are defined 
in gridded or ungridded tables. Thus DAVE-ML compliant simulations may run multiple versions of a particular 
scenario, each with different values of the lookup data w ithin the statistical bounds specified in the tables. 

In addition, DAVE-ML also allows tire specification of uncertainties associated with any signal in a model, 
including inputs, outputs or intermediate values. This capability is included as a “catch all” for model developers 
whose use cases do not fall into the two mentioned above. In these cases, DAVE-ML-compliant software tools 
should substitute appropriately generated random values according to the semantics described below at the 
specified locations. 

6.4.1.2 Approach 

Tlie DAVE-ML approach to statistical uncertainty is the uncertainty element which may be inserted in a model 
wherever the signals should have a statistical distribution about some nominal value. In particular, the 

uncertainty clement maybea sub-clement of the variableDef, griddedTableDet and 
ungriddedTableDei elements. 

Of course, DAVE -MI. models only specify' the statistical properties, not the random values themselves. It is up to 
DAVE-ML-compliant software tools to generate appropriately randomized data according to the specifications in 
the uncertainty element. Likewise it is up to the frameworks to seed the random number generators in some 
problem-appropriate fashion. 1 


1 For example, if the particular simulation run must be repeatable (albeit with randomized variable values ), then 
the random number generator must be seeded from a deterministic value. Such seeding is beyond the scope of 
tie DAVE-ML standard. 
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The following sections summarize the syntax and semantics of the uncertainty element and present some 
examples of its use. 

6.4.2 Syntax 

DAVE-ML supports specification uncertainties distributed normally or uniformly about nominal values. (These 
are the only possible distributions.) Which of these is used depends on the content of the uncertainty element, 
in particular whether the uniformPDF or normalPDF sub-elements are present. Both of these elements in turn 
characterize their distribution using several attributes and elements (described below). The most important of these 
is the bounds element which specifis the numerical characteristics of the uniform or normal distribution. 

6 .4.2.1 The bounds element 

At root, this element is just a scalar numerical value. For example, it could be the upper or low er bound of a 
uniform distribution, or it could quantify the 3-sigma value for a normal distribution. However, D AVK-MI , 
uncertainties may also be applied to data tables in which case there must be scalar values specified for each table 
entry'. 

As a result, the form of a bounds clement depends on the context in which it occurs. When used in scalar contexts, 
it contains a single scalar value. When applied to tables, it contains a dataTable sub-element which itself 
contains the several bounds values the correspond to the data table values. 

Accordingly, a scalar use of the bounds element might appears as follow s. 

<bounds> 

100.0 

</bounds> 

And its use inside a three-element gridded or ungridded table might appear as follows. 

<bounds> 

<dataTable> 

100 . 0 , 200 . 0 , 300.0 
</dataTable > 

</bounds> 

Note: The current DAVE-ML DTD does not enforce this proper use of bounds elements. It is possible for a 
DAVE-ML file to validate (in tire XML sense) but have incorrectly specified bounds (e.g., specify' a table of 
bounds in a scalar context). 

Author's note: This description is incomplete. IVe have left off the use of variableDef and variableRef 
sub-elements. We do not understand these. 

6.4.2. 2 Uniform Distributions 

The DAVE-ML syntax for uniformly distributed uncertainties has the following general form. 

<uncextainty> 

cuniformPDF ef fect-"..."> 

<bounds>...</bounds> 

<bounds>...</bounds> <! — optional --> 

</uniformPDF > 

</uncertainty> 


The effect attribute may be one of the following: additive, multiplicative or absolute. 

Author's note: Our understanding of the multiplicative effect is that it is redundant with the />ercentage effect. 
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Accordingly, we recommend that one or the other he dropped from the DATE -Ml. DTD. Our description here 
reflects that. If we misunderstand the intent of these two effects, or if the DA VE-Ml. community disagrees with 
our preference to avoid such duplication, this description must be fixed. 

The bounds sub-elements specify the bounds of the interval from which the uniformly distributed random values 
arc chosen. For symmetric distributions only one bound is needed. Assymmetric distributions require two. Thus 
the second bounds sub-clement is optional, but at least one must be specified. 

The specific meaning of the effect attribute and bounds element are explained in the semantics section below. 
6. 4.2. 3 Normal Distributions 

The XML syntax for normally distributed uncertainties has the following general form. 

<uncertainty> 

<normalPDF ef£ect="..." numSigmas="..."> 

<bounds>„</bounds> 

<correlatesWith varID="..." /> 

<correlation var ID-"..." corrCoef ="..." /> 

</ norma 1PDF> 

</uncertainty> 


The effect attribute may be one of the following: additive, or mu ltipl icative. The numSigmas attribute 
may have the value of 1, 2 or 3. There must be one (and only one) bounds sub-element. And there may be zero or 
more correlatesWith or correlation sub-elements. 

The values of the varlD attributes of the correlatesWith or correlation sub-elements are references to 
other signals which mast be defined in the model, and the value of the corrCoef attribute is a numerical value. 

Author's note: See the note above regarding multiplicative and percentage effects. 

The specific meaning of these attributes and elements are explained in the semantics section below. 

6.4.3 Semantics 

The uncertainty element specifies statistical characteristics associated with uncertainties about certain 
nominal values. These nominal values might be explicitly defined constant parameter values, tabulated data 
specified in gridded and ungridded tables or implicit (input, output or intermediate) signals calculated during the 
execution of a DAVE-ML tool. The distribution characteristics (c.g., mean, standard deviation, upper low' or 
bounds) are based on the follow ing three numerical values: a bound, the nominal value and (for normal 
distributions) the numSigmas value. 


A bound is specified in bounds elements 2 . The nominal value is in general only known at runtime when the 
model is being executed (although for constant parameters, it is also specified in the DAVE-ML file). The 
numSigmas value is only relevant to normal distributions and is specified in the numSigmas attribute of the 

normal PDF element. 


2 In the simple case, the bounds element contains the numerical bound. However, tire situation is more 
complex for tabulated. See below for a discussion for how to determine the bound in the context of data tables. 
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6.4.3. 1 Uniform distributions 

The use of the uniformPDF element inside an uncertainty element indicates that the corresponding signal 
should be distributed uniformly in some interval about the nominal value. The interval may be symmetrically or 
asymmetrically oriented relative to the nominal value. The content of the uniformPDF element is used to specify 
the distribution interval. 


DAVE-ML-compliant software must randomize the signal in question differently depending on the value the 
effect attribute. 'ITie following table summarizes how the software must calculate the randomized signal in each 
of tlte three allowable cases. 


value of the effect 
attribute 

description 

additive 

The desired signal is the sum of the nominal value and a uniformly distributed 
random value. 

multipl icative 

The desired signal is the product of sun of the nominal v alue and the product of a 
uniformly distributed random value time the nominal value. 

absolute 

The desired signal is a random value uniformly distributed in some interval. (The 
nominal value of the signal is irrelevant in this case.) 


For uniformly distributed random values, the relevant distribution characteristics are the upper and lower bounds 
on the interval from which the random values are drawn. In DAVE-ML. uniform distributions are parameterized 
by one or two bounds sub-elements in the uniformPDF element. When two sub-elements are present, let the 
greater and lesser of these be called big and little, respectively. When only one sub-element is present, let big and 
little both be that same value. The method of determining both bounds depends on the value of the effect 
attribute as explained in the following table. (All calculations are assumed to be floating point.) 

DAVE-ML-compliant software will randomize the signal in question differently depending on the value the 
effect attribute. The following table summarizes how the software must calculate the randomized signal in each 
of the three allowable cases. 


value of the effect 
attribute 

upper/lower bounds of the interval 

additive 

upper = nominalValue + big 
lower = nominalValue - little 

multiplicative 

upper = nominalValue * big 
lower nominalValue * little 

absolute 

upper « big 
lower = little 


6.4.3.2 Normal distributions 

The use of the normalPDF element inside an uncertainty element indicates that the corresponding signal 
should be distributed normally about the nominal value. The content of this element is used to specify the standard 
dev iation of the distribution around the nominal value. 

DAVE-ML-compliant software will randomize the signal in question differently depending on the value the 
effect attribute. The following table summarizes how the software must calculate the randomized signal in each 
of the three allowable cases. 
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value of the effect 
attribute 

description 

additive 

The desired signal is the sum of tire nominal value and a normally distributed 
random value. 

multiplicative 

Tire desired signal is the product of sun of the nominal value and the product of a 
normally distributed random value time the nominal value. 


For normally distributed random values, the relevant distribution characteristics are the mean and standard 
deviation. In DAVE-ML, the mean is always equal to the nominal value, lire method of determining the standard 
deviation depends on the value of the effect attribute as explained in the following table. (All calculations are 
assumed to be floating point.) 


value of the effect 
attribute 

standard deviation 

additive 

stddev = bound / numSigmas 

multiplicative 

stddev = ( (bound-1) * nominal-value) / numSigmas 


6 .4.3.3 Tables of bounds 

Author's note: A description of how the DAVE-ML-compliant software is to determine the appropriate hounds 
values in the context of tables is needed. The algorithms above are not sufficient. There is ambiguity in the case 
of tables, because it is unclear whether the algorithms are applied before or offer interpolation. To clarify, if the 
algorithms were applied before inter/xrlation. then a random value wotdd be generated at each table data point, 
and the desired data value would be the result of interpolation between those two random values. On the other 
hand, if the algorithms were applied after interpolation, then the bounds values themselves would first be 
interpolated to give corresponding bounds values in between the endpoints, and from that value the algorithms 
would be used to generate a random iced value. In general, these two approaches will yield different results, and 
it is not clear which is intended by the DAVE-ML standard. It is wry important (for interoperability >) that this be 
specified unambiguously. This section us where we should /rut an description of the intended approach. 

6.4.4 Examples 

Author '.v note: We have not explicitly inserted examples here. Our intent is that the examples from the current 
Language Reference would fit perfectly here. 
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Appendix B. American National Standard: Flight Dynamics Model 
Exchange Standard (draft BSR/AIAA S-119-201x) 

Permission granted on April 6, 2011: 

AIAA grants you permission to publish the draft of S- 119 in your NASA report as 
an appendix. 

Michael Baden-Campbell 

AIAA Publications bsr/aiaa 

S-119-201X 


American National Standard 

Flight Dynamics Model Exchange Standard 


Draft 2010-04-23 


Sponsored by 

American Institute of Aeronautics and Astronautics 
Approved XX Month 201 X 

American National Standards Institute 

Abstract 

This is a standard for the interchange of simulation modeling data between facilities. The initial objective 
is to allow easy, straightforward exchanges of simulation model information and data between facilities 
The standard applies to virtually any vehicle model (ground, air or space), but most directly applies to 
aircraft and missiles. 
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LIBRARY OF CONGRESS CATALOGING DATA WILL BE ADDED HERE BY AIAA STAFF 


Published by 

American Institute of Aeronautics and Astronautics 
1801 Alexander Bell Drive, Reston, VA 20191 

Copyright © 201X American Institute of Aeronautics and 

Astronautics 

All rights reserved 

No part of this publication may be reproduced in any form, in an electronic retrieval system 
or otherwise, without prior written permission of the publisher. 

Printed in the United States of America 
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Foreword 

This standard was sponsored and developed by the AIAA Modeling and Simulation Committee on 
Standards. Mr. Bruce Jackson of NASA Langley conceived Dynamic Aerospace Vehicle Exchange 
Markup Language (DAVE-ML). DAVE-ML is the embodiment of the standard in XML. The DAVE-ML 
reference document, including examples of its use, and the document type definition for the XML 
implementation are included in this standard (Annex B). 

This implementation was then tested by trial exchange of simulation models between NASA Langley 
Research Center (Mr. Bruce Jackson), NASA Ames Research Center (Mr Thomas Alderete and Mr Bill 
Cleveland), and the Naval Air Systems Command (Mr. William McNamara and Mr. Brent York). 
Numerous improvements to the standard resulted from this testing. 

At the time of approval, the members of the AIAA Modeling and Simulation CoS were: 


Bruce Hildreth, Chair 

Science Applications International Corporation (SAIC) 

Bruce Jackson 

NASA Langley Research Center 

Michael Madden 

NASA Langley Research Center 

Geoff Brian 

Defence Science and Technology Organisation (DSTO) 

Brent York 

Indra Systems, Inc. 

Michael Silvestro 

Charles Stark Draper Laboratory, Inc. 

Victoria Chung 

NASA Langley Research Center 

Bimal Aponso 

NASA Ames Research Center 

Jean Slane 

Engineering Systems Inc. 

Peter Grant 

University of Toronto 

William Bezdek 

Boeing Phantom Works 

Jon Berndt 

Jacobs 


The above consensus body approved this document in Month 200X. 

The AIAA Standards Executive Council (VP-Standards Name, Chairman) accepted the document for 
publication in Month 201 X. 

The AIAA Standards Procedures dictates that all approved Standards, Recommended Practices, and 
Guides are advisory only. Their use by anyone engaged in industry or trade is entirely voluntary There is 
no agreement to adhere to any AIAA standards publication and no commitment to conform to or be 
guided by standards reports In formulating, revising, and approving standards publications, the 
committees on standards will not consider patents that may apply to the subject matter Prospective users 
of the publications are responsible for protecting themselves against liability for infringement of patents or 
copyright or both. 
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Introduction 

The purpose of this standard is to clearly define the information and format required to exchange air 
vehicle simulation models between simulation facilities (see Figure 1). This standard simulation 
interchange format is implemented in XML and is described fully in Annex B of this document. 



Figure 1 — Model exchange via a standardized format 
The standard interchange format includes: 

a) Standard variable name definitions — to facilitate the transfer of information by using these standard 
variables as a “common language.” The interchange format can be used without using standard 
variable names. However, it will be more difficult because the exported model will have to include 
explicit definitions of all variables instead of just a subset unique to the particular model. 

b) Standard function table definition — to allow easy transfer of non-linear function tables of arbitrary 
dimension. 

c) Standard coordinate system and reference frame definitions — used by the variable names and 
function tables to clearly define the information being exchanged. 

d) Standard static math equation representation — for definition of static equations forming part of 
aerodynamic, propulsive or other models. 

A specialized grammar of XML provides a format for the exchange of this information, therefore each 
organization is required to design import/export tools that comply with the standard one time only. 

Use of this standard will result in substantially reduced cost and time necessary to exchange aerospace 
simulations and model information. Test cases have indicated an order of magnitude reduction in effort to 
exchange simple models when utilizing this standard. Even greater benefits could be attained for large or 
complicated models. 
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Trademarks 

The following commercial products that require trademark designation are mentioned in this document. 
This information is given for the convenience of users of this document and does not constitute an 
endorsement. Equivalent products may be used if they can be shown to lead to the same results 

Simulink® 

MATLAB® 
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1 Scope 

This standard establishes definitions of the information and format used to exchange air vehicle 
simulations and validation data between disparate simulation facilities This standard is not meant to 
require facilities to change their internal formats or standards. With the concept of an exchange standard, 
facilities are free to retain their well-known and trusted simulation hardware and software infrastructures 
The model is exchanged through the standard, so each facility only needs to create import/export tools to 
the standard once. These tools can then be used to exchange models with any facility at minimal effort, 
rather than creating unique import/export tools for every exchange 

The standard includes a detailed convention for representing simulation variables The purpose of this is 
to unambiguously describe all variables within the model when it is exchanged between two simulation 
customers or facilities. The variable representation includes explicit specification of all coordinate 
systems, units, and sign conventions used. XML is used as the mechanism to facilitate automation of the 
exchange of the information. Based on the definitions in the standard, a list of recommended but non- 
obligatory simulation variable names is included in Annex A This list of standard variable names should 
further simplify the exchange of information, but is not required for use of the standard 

The standard includes capabilities for a model to be self-validating and self-documenting, with the 
provenance of a model’s components included within the model and transferred with it. Statistical 
descriptions of the quality of a model may also be included 
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2 Tailoring 

The requirements defined in this standard may be tailored to match the actual requirements of any 
particular program or project Tailoring of requirements should be undertaken in consultation with the 
procuring authority where applicable. 

NOTE Tailoring is a process by which individual requirements or specifications, standards, and related documents 
are evaluated and made applicable to a specific program or project by selection, and in some exceptional cases, 
modification and addition of requirements in the standards. 

The following sections provide further guidance on specific tailoring situations 

2.1 Partial Use of the Standard 

2.1.1 General 

Not all aspects of this standard may be applicable to all models or simulation applications. The following 
guidelines are provided to encourage appropriate use of the standard in a number of example situations 

2.1 .2 Creating a New Simulation Environment 

This situation calls for use of the complete standard. It is hoped that the team developing the new 
simulation environment would, if necessary, add to the list of standard variables and coordinate systems. 

2.1.3 Creating a New Simulation Model in an Existing Simulation Environment 

This situation is defined as creating a new system model (aircraft dynamic model for example) that will 
run in an existing simulation environment It is expected that this is the most commonly performed work 
that will see benefit by application of this standard 

In this case the following tailoring guidelines are applicable. 

a) Apply the standard to the new development aspects of the project and all the function tables 

b) Assuming that most or all of the standard variable names and coordinate systems are applicable to 
the simulation, use them for the new code developed for the simulation. 

c) In the existing simulation environment that is being reused, for example the equations of motion, 
there is no need to rewrite the code to use the standard variable names or coordinate systems. 
However, in most cases the coordinate systems used in existing simulation environments will be 
covered in the standard coordinate system definitions herein (Section 5) Therefore the standard 
coordinate systems can easily be referenced when documenting the simulation and interfaces 
between the new simulation components and those reused 

2.1.4 Creating or Updating a Simulation with a Long Life Expectancy 

A pilot training simulator is an excellent example of this type of simulation. This simulation may only be 
updated every 3-10 years, so at first glance the standard may seem to be less applicable. 

In fact the opposite is true. It is because of the infrequent maintenance that application of the standard is 
critical. In this case, in each new software update, the original developers (or previous updaters) are 
probably no longer available, and the update is being performed by different personnel Software 
developed using the standard should be easier for the new software team to understand They are 
working with clear variable definitions with which they are familiar, The function table format is understood 
and the functions themselves are better documented The coordinate system definitions are clear 
Changes are recorded for the benefit of any future software update 

In simulations with a long expected life, use of the state, state derivative control and output conventions 
as part of the variable naming convention becomes critical as these variables form the core of the model 
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and the significant inputs. It is important that the personnel modifying the simulation are able to easily 
identify the states, state derivatives and controls 

2.2 Implementing the Standard in a non-flat or non-scalar namespace 

The variable naming convention defined within the standard makes no assumption as to the hierarchy of 
data components, such as object-oriented model implementation or multi-dimensional storage of matrices 
and vectors The standard can accommodate these implementations through the use of a period (.) 
inserted before the optional domain name (e.g. aero . bodyForceCoef f icient_X) or through the use 
of an appropriate indexing mechanism for the chosen implementation language (e.g. 
aerobodyForceCoeff icient [0] or aerobodyForceCoef f icient (1) ). However, it Should not be 
expected that other members of the simulation community maintain implementation-specific conventions. 
Therefore, on export these variable constructs, should be converted to the flat, scalar namespace defined 
herein 

2.3 New and Reused Software Tailoring Guidance 

The longer the expected life of the simulation, the more helpful the application of the standard becomes. 
The above tailoring guidelines may be categorized into two common situations; new and reused code 

New simulation code should 

a) use coordinate system definitions (Section 5) that coincide with the definitions in the standard; 

b) use standard variable names (Section 6) to facilitate consistency and simplify documentation 
requirements; 

c) apply the convention for states, state derivatives and controls wherever possible; and 

d) use standard function tables (Section 7) for all function tables. 

NOTE This facilitates consistency in the data, the documentation of the data, and collaboration with other 
organizations to improve or debug the data 

Reused simulation code should reference the standard only when convenient to document interfaces with 
new code 

2.4 Creating New Variable Names and Coordinate Systems 

The standard variable names and coordinate system definitions are included in the standard to facilitate 
communication They provide a “common language” for the exchange For example, it is not enough to 
exchange the values of the lift coefficient function. As a minimum, the independent variables used to 
define the function and their units, sign convention, and reference coordinate system must be defined. 
This need to precisely define variables is facilitated by having standard variable names and coordinate 
systems Of course, new variable names, definitions, and other convenient coordinate systems may be 
used to exchange models between simulation facilities However, in such cases, the exporters and 
importers must carefully define these variables and coordinate systems, or the exchanged model may not 
produce the desired results. Use of standard variable names and coordinate systems facilitates the 
exchange 

This standard includes a methodology for creating new standard variables Its use is encouraged. 
Annex C provides the URL for submitting additional standard variable names and coordinate systems or 
comments on existing standard variable names and coordinate systems. 
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3 Applicable Documents 


The following documents contain provisions which, through reference in this text, constitute provisions of 
this standard For dated references, subsequent amendments to, or revisions of, any of these 
publications do not apply. However, parties to agreements based on this standard are encouraged to 
investigate the possibility of applying the most recent editions of the normative documents indicated 
below. For undated references, the latest edition of the normative document referred to applies. 


AIAA R -004-1 992 
IST-CR-90-50 

www w3.org/XML 
www.w3.org/Math 

ISO 19111:2007 
ISO 1151-1:1988 

ISO 1151-2:1985 

ISO 1151-3:1989 

ISO 1151-4:1994 

ISO 1151-5:1987 


Atmospheric and Space Flight Vehicle Coordinate Systems 

Distributed Interactive Simulation (DIS Application Protocols, Version 2, 
March 1994) 

Extensible Markup Language (XML) 10 (Fifth Edition ), 2008-11-26 

Mathematical Markup Language (MathML) Version 2 0 (Second Edition), 
2003-10-21 

Geographic information - Spatial referencing by coordinates 

Flight dynamics - Concepts, quantities, and symbols - Part 1: Aircraft 
motion relative to the air 

Flight dynamics - Concepts, quantities, and symbols - Part 2 Motions of 
the aircraft and the atmosphere relative to the Earth 

Flight dynamics - Concepts, quantities, and symbols - Part 3: 
Derivatives of forces, moments and their coefficients 

Flight dynamics - Concepts, quantities, and symbols - Part 4; Concepts, 
quantities and symbols used In the study of aircraft stability and control 

Flight dynamics - Concepts, quantities, and symbols - Part 5: Quantities 
used in measurements 


ISO 1 1 51 -6: 1 982 Terms and symbols for flight dynamics - Part 6 Aircraft geometry 


ISO 80000-1 2009 Quantities and Units - General 
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4 Vocabulary 

4.1 Acronyms and Abbreviated Terms 


AIAA 

AND 

ANR 

ANSI 

CM 

DAVE- ML 

DIS 

DTD 

FE 

GE 

HLA 

1C 

ISO 

ISQ 

MathML 

MRC 

MSL 

RWD 

SI 

URL 

WGS 

XML 


American Institute of Aeronautics and Astronautics 
aircraft nose down 
aircraft nose right 

American National Standards Institute 
center of mass 

Dynamic Aerospace Vehicle Exchange Markup Language 

Distributed Interactive Simulation 

Document Type Definition 

Flat Earth coordinate system 

Geocentric Earth fixed coordinate system 

High Level Architecture 

initial condition 

International Organization for Standardization 

International System of Quantities 

Mathematical Markup Language 

moment reference center 

Mean sea level 

right wing down 

Systeme Internationale d'Unites 
Uniform Resource Locator 
World geodetic system 
extensible Markup Language 


4.2 Terms and Definitions 

For the purposes of this document, the following terms and definitions apply. 

Center of mass 

This standard uses center of mass (CM) as the default location for several coordinate systems. The long- 
standing aeronautical tradition is to refer to this location as the center of gravity (CG) Center of gravity 
and center of mass are interchangeable for vehicle modeling on or above a large gravitational body in 
hydrostatic equilibrium like the Earth. However, the difference between CM and CG can become 
significant when a vehicle maneuvers near small, irregularly shaped gravitational bodies (e g, asteroids) 
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Thus, center of mass Is the more correct term for this important aerodynamic and kinematic reference 
point 

Coordinate system 

A measurement system for locating points in space and attached to a reference frame (Stevens and 
Lewis, 2003). In this standard they will be orthogonal right-handed triads unless specifically noted. 

Ground 

Smooth surface of the earth at the nadir, not necessarily MSL. 


Mean Sea Level 

The zero elevation reference in the simulation, normally the geoid Although many simulations treat MSL 
and the smooth surface of the earth as equivalent this is not always true For example, the WGS84 
model equates MSL with the geoid, not the smooth surface. 

Presentation coordinate system 

The specific coordinate system in which a variable or vector is presented (or expressed). For example, a 
specific vector may be presented (expressed) in the body axis coordinate system, the geocentric Earth 
(ge) coordinate system, or one of the alternatives presented in Section 5. The value of the vector’s 
components (e g X, Y, & Z) differs depending on the presentation coordinate system. The presentation 
frame only determines how the vector is expressed as X, Y, and Z components, as the specific vector of 
an object is invariant with respect to any arbitrary coordinate frame (i.e. they are contravariant rank one 
tensors). In other words, the specific vector in two presentation frames differs only by a linear 
transformation (i.e. a rotation matrix). When one “presents" or “expresses” the vector in a presentation 
coordinate system, that presentation coordinate system is treated as if it is instantaneously fixed relative 
to the observer for the given time t (even if the presentation coordinate system is translating and rotating 
relative to the observer) 

The presentation coordinate systems is identified in variable names by the initial coordinate system prefix 

Reference frame 

Frames for short A general definition for a reference frame is: three or more non-colinear points on a rigid 
body define a reference frame (Stevens and Lewis, 2003). Unlike a coordinate system, a reference frame 
has no fixed origin, it is in essence a rigid body wherein all points are fixed in position relative to each 
other The location of a point or vector in a frame is expressed using a specified coordinate system Any 
number of points or vectors may be expressed with any number of coordinate systems (with no relative 
motion) in the same frame For example, the Earth is often a reference frame and may have the 
geocentric Earth (ge) coordinate system attached to the center, and any number of user defined topodetic 
coordinate systems (such as runways or launch sites) used to locate and orient fixed objects on the 
Earth. Note however an object moving on or above the surface of the Earth would be in a different 
reference frame 

Reference coordinate system 

The coordinate system that defines the frame of interest of a rotational measurement such as attitude, 
angular rate or angular acceleration. Identified in variable names by the “of” component If not present, 
the default reference coordinate system is the body coordinate system. 

Reference point 

The point of interest of a translational measurement such as position, velocity or acceleration. Identified in 
variable names by an “of” component. If not specified, the default reference point is the ownship's center 
of mass. 

Relative coordinate system 

A coordinate system that defines the origin of a measurement such as position, velocity or acceleration 
(translational or rotational). Identified in variable names by the “wrt” component. If not specifed, the 
default relative coordinate system is the same as the presentation coordinate system for translation and 
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the locally-level coordinate system for rotations. 

Observer coordinate system 

A coordinate system from which motion of a point (a velocity, acceleration or higher derivative) is 
observed (or measured). In many cases this coordinate system is in the same reference frame as the 
relative coordinate system, however in the most general case, may exist in a different frame. The 
magnitude and direction of velocity (and higher derivatives) differ depending on the observer coordinate 
system due to the fact that the relative coordinate system may be in motion relative to the observer. 
Identified in variable names by the “obsFr” component. If not specified, the observer coordinate system 
defaults to the same coordinate system as the relative coordinate system . 

Velocity 

The first derivative of position; in the general case, can be applied to either translational or rotational rate- 
of-change of position. This term normally applies to translational motion; the rotational equivalent is 
normally called “angular rate.” 

Inertial velocity 

The special case of a velocity for which the relative reference and observer coordinate systems are an 
inertial frame. 

Breakpoint 

A value of an independent variable at which the value of its dependent variable is specified, or the x 
coordinate (or abscissa) of a one dimensional table 

Confidence interval 

An estimate of the computed or perceived accuracy of the data 

Dependent variable 

An output that is obtained by evaluation of a tabulated function or a MathML expression 
EXAMPLE For Cl(o,P), Cl is the dependent variable, also called the output. 

Independent variable 

The input(s) to a function table or a MathML expression 
EXAMPLE For Cl(clP), a and p are independent variables. 

One-dimensional table 

A table whose values are based upon only one independent variable 
EXAMPLE Cl(ol) may be represented by a one-dimensional table. 

Two-dimensional table 

A table whose values are based upon two independent variables 
EXAMPLE Cl(o,P) may be represented by a two-dimensional table. 

Static equation 

A mathematical statement where the output (left hand side) does not have direct dependence (right hand 
side) on a simulation state 

Simulation states (and state derivatives) 

In the formulation of a non-linear simulation model shown as 

x = f,{x(t),u(t),w{t)} 
y=f i{x{t),u(t)) 

where 
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t represents a vector of the simulation states. 

.it represents a vector of the simulation state derivatives. 
u represents a vector of the simulation controls 
y represents a vector of the simulation outputs 
w represents a vector of disturbances 
Function Table 

The numeral set of data points used to represent the value of an independent variable as a function of the 
value(s) of one or more independent variables 

EXAMPLE C L (ct,p) may be represented by a function table. 

Gridded Table 

A multi-dimensional function table in which all independent variable breakpoints are constant across the 
function range, but not necessarily evenly spaced 

NOTE 1 This is sometimes called an orthogonal table. 

NOTE 2 All one-dimensional tables are gridded tables. 

EXAMPLE A gridded two-dimensional function 



Gridded Function f(x 1 ,x 2 ) 


X 2 -wie© breakpoints 


X^-wise breakpoints 


Ungridded Table 

A multi-dimensional function table in which the independent variable breakpoints need not be constant 
across the function range 

NOTE This is sometimes called a non-orthogonal table. 

EXAMPLE An ungridded two-dimensional function 
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Ungridded function f(x 1 ,x 2 ) 


X 2 -wise regular spacing 


XfWise irregular spacing 
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5 Standard Simulation Coordinate Systems 

5.1 Background / Philosophy 

Most of the coordinate system definitions discussed herein were taken from existing standards, the 
ANSI/AIAA Recommended Practice for Atmospheric and Space Flight Vehicle Coordinate Systems 
(ANSI/AIAA R-004-1 992) and the Distributed Interactive Simulation (DIS Application Protocols, Version 2, 
IST-CR-90-50, March 1994). AIAA R-004-1992 is based on ISO 1151-1:1988 and ISO 1151-3:1972. 

Coordinate system standards are also reflected in the variable naming convention. When applicable, the 
coordinate system is included in the variable name (see Section 6) 

5.1 .1 Coordinate System Conventions 

In general, ANSI/AIAA R-004-1992 is the normative reference for coordinate system definitions These 
coordinate systems are discussed in Table 1 However, it is important to emphasize the correlation of the 
AIAA document and the Distributed Interactive Simulation (DIS) coordinate systems, The geocentric Earth 
fixed coordinate system and body coordinate system are both used in DIS and High Level Architecture 
(HLA) simulations 

5.1 .1 .1 Geocentric Earth Fixed Coordinate System 

The Geocentric Earth Fixed Coordinate System (coordinate system 1.1.3 of Table 1) is identical to the 
DIS “Geocentric Cartesian Coordinate System" (also referred to as “World Coordinate System" in the 
DIS). 

All variables referenced to this coordinate system use “ge" as part of their name for the Geocentric Earth 
Fixed Coordinate System. This coordinate system is also frequently called “Earth-centered, Earth-fixed.” 

5.1.1.2 Body Coordinate System 

Another standard coordinate system is the Body Coordinate System (coordinate system number 1.1.7 in 
ANSI/AIAA R-004-1992). This is identical to the DIS "Entity Coordinates System.” The body coordinate 
system is identified in the variable names by "body" 

5.1 .1 .3 Additional Coordinate Systems 

In addition to the coordinate systems defined in ANSI/AIAA R-004-1992, this standard has added the 
Moment Reference Center, Flat Earth, Locally Level, and Vehicle Reference (or Structural) coordinate 
systems The Moment Reference Center coordinate system is a special case body coordinate system 
(number 1.1.7 in ANSI/AIAA R-004-1992, number 1.1.5 in ISO 1151-1:1998). The Flat Earth and Locally 
Level coordinate systems are respectively variants of the Normal Earth-fixed coordinate system (number 
114 in ANSI/AIAA R-004-1992, number 1.1.2 in ISO 1151-1:1998) and the Vehicle-carried normal Earth 
coordinate system (number 1.1.6 in ANSI/AIAA R-004-1992, number 1.1.4 in ISO 1151-1:1998) Both 
these coordinate systems are normally used in conjunction with an assumption that the Earth forms an 
inertial reference frame. They are useful for simple simulations, and for creating vehicle model validation 
data. The Vehicle Reference coordinate system is a body coordinate system that may be used to locate 
vehicle components within the structure of the vehicle. 

The moment reference center coordinate (MRC) system may be used to locate objects in the vehicle. Its 
axes are aligned with the body coordinate system, however, its origin is fixed at the moment reference 
center of the vehicle while the body coordinate system origin is at the center of mass (CM) and moves as 
the center of mass (CM) moves. 

The moment reference center coordinate system is identified in the variable names by “mrc" 

The flat Earth coordinate system is based on a fixed, non-rotating, flat Earth with no mapping to a round 
Earth coordinate system, and therefore, latitude and longitude are inappropriate (but can be scaled for 
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small maps). The purpose of this coordinate system is to allow, if desired, vehicle checkout simulation to 
be performed in this coordinate system. This simplifies the use of this standard by simulation facilities 
that do not normally use a round or oblate spheroidal, rotating Earth model 

The flat Earth coordinate system is identified in the variable names by ”f e". 

The locally level coordinate system is the reference coordinate system for angles and angular motion It’s 
origin is fixed at the vehicle center of mass. 

The locally level coordinate system is identified in variable names by “li" 

The vehicle reference coordinate system is used to locate vehicle components It is fixed to the vehicle 
structure and does not move. The specific definition differs for each vehicle. Sometimes the vehicle 
system may be the weight and balance reference system for the vehicle. The X origin is often in front of 
the vehicle, the Y origin in the centerline of the vehicle and the Z origin below the vehicle The X-axis is 
often called the fuselage station and is often positive aft, the Y-axis is called butt line and is often positive 
to right, and the Z-axis is the waterline and is often positive up. However, these definitions may change 
with the vehicle and a manufacturing reference system may instead be used 

The vehicle reference system is identified in variable names by “vrs" 

5.2 Complete List of Coordinate Systems 

The coordinate systems that are referenced are taken largely from paragraph 1.1 of ANSI/AIAA R-004- 
1992. The moment reference center, flat Earth and locally level coordinate systems for atmospheric flight 
simulation approximation are additional to that reference A vehicle reference coordinate system is added 
for the purpose of locating systems and subsystems in the vehicle Table 1 is the comprehensive list of 
coordinate systems that may be used under this standard. 

The first column in Table 1 provides the abbreviation recommended for each coordinate system. The 
coordinate system may be referenced in a variable name by use of its abbreviation See Section 6 on the 
variable naming convention. 


Table 1 — Standard coordinate systems 


Reference 

Abbreviation 

R-004-1 992 
Paragraph 
Number 

Term 

Definition 

Symbol 

ei 

(for Earth 
centered 
inertial) 

1.1.1 

Geocentric 
inertial coordinate 
system 

(See Appendix 
D.2 of R-004 for a 
modification of 
this system used 
for launch 
vehicles.) 

An inertial reference system of the FK5 
mean equator and equinox of J2000.0 has 
the origin at the center of the Earth, the X- 
axis being the continuation of the line from 
the center of the Earth through the center of 
the Sun toward the vernal equinox , the Zi- 
axis pointing in the direction of the mean 
equatorial plane s north pole, and the Yi-axis 
completing the right-hand system 
(See Figure 1A in R-004) 

X.Y.Z, 

Not used, this 
forms a basis 
for other 
definitions 

1.1.2 

Earth-fixed 

coordinate 

system 

A right-hand coordinate system, fixed 
relative to and rotating with the Earth, with 
the origin and axes directions chosen as 
appropriate 

XoyoZo 

9® 

(also called 
Earth -centered, 

1.1.3 

Geocentric Earth- 
fixed coordinate 
system 

A system with both the origin and axes fixed 
relative to and rotating with the Earth (1 .1 .2). 
The origin is at the center of the Earth, the 
Xn-axis beinq the continuation of the line 

XoyoAs 
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Reference 

Abbreviation 

R-0 04-1 992 
Paragraph 
Number 

Term 

Definition 

Symbol 

Earth-fixed) 



from the center of the Earth through the 
intersection of the Greenwich meridian and 
the equator, the z.;.-axis being the mean spin 
axis of the Earth, positive to the north, and 
the yo-axis completing the right-hand 
system 





(See Appendix D 3 in R-004-1992) 



1.1.4 

Normal Earth- 
fixed coordinate 
system 

An Earth-fixed coordinate system (1.1.2) in 
which the z-.-axis is oriented according to the 
downward vertical passing through the origin 
(from the origin to the nadir). 

(See Figure 1C in R-004-1992) 

XqVo’o 

VO 

1.1.5 

Vehicle-carried 

orbit-defined 

coordinate 

system 8 

A system with the origin fixed in the vehicle, 
(the default being the center of mass), in 
which the Zo-axis is directed from the 
spacecraft toward the nadir, the y 0 -axis is 
normal to the orbit plane (positive to the right 
when looking in the direction of the 
spacecraft velocity), and the x 0 -axis 
completes the right-hand system 
(See Figure 1A in R-004-1992) 

x 0 >V -0 

ve 

1.1.6 

Vehicle-carried 
normal Earth 
coordinate 
system 8 

A system in which each axis has the same 
direction as the corresponding normal Earth- 
fixed axis, with the origin fixed in the vehicle, 
the default being the center of mass 

XQyoZQ 

body 

1.1.7 

Body coordinate 
system 8 

A system fixed in the vehicle, with the default 
origin being the center of mass, consisting of 
the following axes: 

xyz 



Longitudinal axis 

An axis in the reference plane or, if the origin 
is outside that plane, in the plane through the 
origin parallel to the reference plane, and 
positive forward. b In aircraft or missiles, this 
is normally from the CM forward towards the 
nose in the vertical plane of symmetry. It is 
also normally parallel to the waterline of the 
vehicle. 

X 



Lateral axis 

An axis normal to the reference plane and 
positive to the right of the x-axis (henceforth, 
positive to the right). 

y 



Normal axis 

An axis that lies in or parallel to the 
reference plane, whose positive direction is 
chosen to complete the orthogonal, right- 
hand system xyz. 
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Reference 

R-0 04-1 992 

Term 

Definition 

Symbol 

Abbreviation 

Paragraph 





Number 




mrc 

none 

A body 

This is a body coordinate system. The 

x i&U z M 

(for moment 

reference 

center) 


coordinate 

default origin is not fixed at the center of 



system 
(not in R-004) 

mass, but at the moment reference center 
(mrc) and therefore does not move. It 
consists of the following axes: 




Longitudinal axis 

An axis in the reference plane or, if the origin 
is outside that plane, in the plane through the 
origin parallel to the reference plane, and 
positive forward. b In aircraft or missiles, this 
is normally from the MRC forward towards 
the nose in the vertical plane of symmetry. It 
is also normally parallel to the waterline of 




Lateral axis 

the vehicle. 





An axis normal to the reference plane and 
positive to the right. 




Normal axis 

An axis that lies in or parallel to the 
reference plane, whose positive direction is 
chosen to complete the orthogonal, right- 
hand system xyz. 


wind 

1.1.8 

Air-path system 8 

A vehicle carried system with the origin fixed 

v a>'a-a 

(for wind 
coordinate 



in the vehicle, located at the center of mass, 
consisting of the following axes: 


system) 


.vj,-axis; 

An axis in the direction of the vehicle velocity 

- v a 



air-path axis 

relative to the air 



ya-axis; 
lateral air-path 
axis; cross- 
stream axis 

An axis normal to the air-path axis and 
positive to the right of the plane formed by 
the x a and Za axes 

>'a 



r a -axis; 

An axis 

r a 



normal air-path 

■ in the reference plane or, if the 




axis 

origin is outside that plane, 
parallel to the reference plane, 
and 





• normal to the air-path axis. 





The positive direction of the z.-axis is 
chosen so as to complete the orthogonal, 
right-hand system x a yaZ a . 


sa 

1.1.9 

Intermediate 

A system with the origin fixed in the vehicle, 

*s.VsZs 

(for stability 
axis system) 


coordinate 

system 8 

located at the center of mass, consisting of 
the following axes 
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Reference 

Abbreviation 

R-0 04-1 992 
Paragraph 
Number 

Term 

Definition 

Symbol 



.v s -axis 

The projection of the air-path x axis on the 
reference plane, or, if the origin is outside 
that lane, on the plane through the origin, 
parallel to the reference plane 

*S 



Vs-axis 

An axis normal to the reference plane and 
positive to the right, coinciding with or 
parallel to the lateral axis (1.1.7). 

ys 



r s -axis 

An axis that coincides with or is parallel to 
the normal air-path axis so as to complete 
the orthogonal right-hand system 

2g 

*P 

1.1.10 

Flight-path 

coordinate 

system 0 

A system with the origin fixed in the vehicle 
(af the center of mass) and in which the xi<- 
axis is in the direction of the flight-path 
velocity relative to the Earth 





The axis is normal to the plane of 
symmetry and positive to the right. 





The Jk axis completes the orthogonal right- 
hand system 


aa 

1.1.11 

Total-angle-of- 
attack coordinate 
system 0 

(USA practice: 
aeroballistic 
coordinate 
system.) 

A system with the origin fixed in the vehicle, 
at the center of mass, in which the x r axis is 
coincident with the x-axis in the body 
coordinate system (1.1.7). The n-axis is 
perpendicular to the plane formed by the Xt- 
axis and the velocity vector, positive to the 
right. The z|-axis is formed to complete the 
orthogonal, right-hand system. 

TO 

f e 

None 

Flat Earth system 
(not in R-004) 

The Flat Earth coordinate system origin is 
situated on the Earth's surface directly under 
the center of mass of the vehicle at the 
initialization of the simulation The AFE-axis 
points northwards and the 1're-axis points 
eastward, with the ZpF.-axis down The.VFF. 
and 1 'ff. axes are parallel to the plane of the 
flat Earth. 

AfeI'feZfE 

n 

None 

Locally Level 

coordinate 

system 

(not in R-004) 

A vehicle related coordinate system (1.1 .6) 
with the origin instantaneously at the 
ownship center of mass. The Z^L-axis 
passes through the vehicle center of mass 
and points towards the nadir The A'u.-axis is 
parallel to the smooth surface of the Earth 
and oriented toward true north in the 
geometric Earth model The Tu.-axis is 

-TliAiAl 
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Reference 

Abbreviation 

R-004-1992 

Paragraph 

Number 

Term 

Definition 

Symbol 




parallel to the smooth surface of the Earth 
completing the right hand triad (East) The 
locally level coordinate system is valid for 
geometric or flat Earth models. 


vrs 

None 

Vehicle 

Reference 

system 

(not in R-004) 

A vehicle fixed coordinate system used to 
locate items in the vehicle It is often the 
weight and balance coordinate reference 
system for the vehicle, or the manufacturing 
coordinate reference system The VRS may 
not be a right-handed coordinate system 

X-axis is the longitudinal reference It may be 
the Fuselage Station line, normally 0 being in 
front of the vehicle with the coordinate 
increasing aft. 

Y-axis is the lateral reference. It may be the 
Butt line perpendicular to the vertical 
symmetric plane of the vehicle and in the 
geometric center of the vehicle. Positive to 
the right facing forward (Starboard) 

Z-axis is the vertical reference. It may be the 
Waterline and its origin is normally under the 
vehicle, positive up. 


a By default, the origins of the coordinate systems selected from ANSI/AIAA-R-004-1 992 1.1.5 through 
1.1.11 coincide and are at the center of mass If that is not the case, it is necessary to distinguish the 
different origins by appropriate suffixes and additional coordinate system references. 

b The reference plane should be a plane of symmetry, or a clearly specified alternative. This may be 
specified by the vehicle reference system (vrs). 

italics indicate clarifications to ANSI/AIAA-R-004-1992 


5.3 Summary 

This coordinate system standard should be followed for all future equations of motion. It is necessary for 
unambiguous reference to coordinate systems in simulation variable names 

5.4 References 

ANSI/AIAA Recommended Practice R-004-1992, Atmospheric and Space Flight Vehicle Coordinate 
Systems, 28 February 1992 

Distributed Interactive Simulation (DIS Application Protocols, Version 2, IST-CR-90-50, March 1994) 

ISO 1151-1:1988, Flight Dynamics - Concepts, quantities and symbols- Part 1: Aircraft motion relative to 
the air. 15 April 1988 

ISO 1151-3:1989, Flight dynamics - Concepts, quantities, and symbols - Part 3 Derivatives of forces, 
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moments and their coefficients, 01 April 1989 
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6 Standard Simulation Variables 

6.1 Background / Philosophy 

6.1.1 Rationale for Having Standard Variable Name and Naming Conventions 

The standard variable names and coordinate system definitions are part of this standard to facilitate 
communication. They provide a “common language” for information exchange. For example, to 
unambiguously exchange a function representing a lift coefficient, the minimum information required to be 
transmitted includes the independent variables used to define the function (such as angle-of-attack, 
angle-of-sideslip, Mach number, Reynolds number and aircraft configuration), their units, their sign 
conventions, and their reference coordinate systems Such an exchange will be facilitated by using 
standard variable names and coordinate systems. 

If a model uses standard variable nomenclature the information defining the model data may be 
exchanged entirely by reference to this standard. Additionally, adherence to the variable naming 
convention included herein will allow the list of standard variables to grow as needed by the user 
community Use of the convention to maintain consistent variable names will ease user workload and 
maximize the benefits to be obtained from this standard 

Positions, angles, velocities and angular velocities referred to in this standard are defined in accordance 
with ANSI/AIAA R -004-1 992. 

6.2 Variable Naming Convention 

The purpose of the naming convention is to provide guidance for the creation of variable names 
consistent with the standard variable names (Annex A). This will allow expansion of Annex A over time, 
further expanding the set of names available to facilitate model exchanges. 

Variable names are constructed from components that jointly serve to fully define the variable in its 
particular application. A combined mixed case and underscore variable name convention is used In 
variable name components that consist of multiple words, the first letter of each word is capitalized 
(medial capitals). Where the simulation language in use allows it, and where the logic of the simulation 
requires it, an underscore may be replaced by a period (.) to indicate an object member, or by 
parentheses or brackets to indicate an array member. 

The following general rules for naming all variables shall be followed. 

a) Variables shall have meaningful names. 

b) Variable names shall not exceed 63 characters in length. Brief, but complete, names are most 
effective. 

c) Names shall be constructed using US-ASCII 7-bit character encodings 

6.3 Variable Name Methodologies 

There are three methods specified for defining variables consistent with this standard. Different methods 
are described for 

a) Position variables (linear or angular), arrays or structures 

b) Motion variables (velocities, accelerations, or higher derivatives, both linear and angular), arrays 
or structures 

c) All other variable names 

The naming convention for position variables and for variables describing motion are different than other 
types of variables because of the general requirements to specify coordinate systems that uniquely define 
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position and velocity. 

In additional, the following guidelines for capitalization when creating variable names are provided: 

d) The first letter in the variable name is lower case Similarly, the first letter in the prefix and the first 
component following the prefix are lower case 

e) The first letters in acronyms and abbreviations are capitalized 

f) Distinct components in variable names, after the first component, shall begin with a capital letter. 

g) Units are not capitalized unless the unit abbreviation itself is. 

6.3.1 The Physical Basis for the Position, Velocity, Acceleration (and Derivatives thereof) 

Naming Convention 

To ground the discussion of variable names it is useful to refer to a standard dynamics text and to review 
the equation of Coriolis Figure 2 below shows the derivation of the three-dimensional linear velocity of 
point p with respect to coordinate system M as observed from coordinate system O Coordinate system M 
has translational and rotation motion relative to O; in the figure, ft) depicts the angular rate of M with 
respect to O 



Figure 2 — Rotating reference frames and relative geometry 


The velocity of p with respect to M as observed from O is the vector difference of the velocity of p with 
respect to O and the velocity of M with respect to O (both of which are observed from O): 

o ■ _ o ■ _o- 

r plM~ r plO r MIO (1) 

For this discussion, the vector notation used by Stevens and Lewis is used (see Figure 3 below) but other 
notations are equally valid. Using the equation of Coriolis (Stevens and Lewis equation 1.2-10), the 
velocity of p with respect to O observed from O is given by: 

O- —°' , M • . v 

r plO~ r MlO ' r p/M'^MlO'^^plM ( 2 ) 

The left-hand side term and the first right hand side term in equation (2) are the velocity terms in the right- 
hand side of equation (1). Combining the two equations produces the following relationship: 
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r plM~ r + plM (3) 

Equation (3) shows that the velocity of p with respect to M as observed from 0 does not equal the velocity 
of p with respect to M as observed from M in the general case This illustrates the need to clearly specify, 
for derivatives of a linear position vector, the coordinate systems that define the point (this standard 
designates the point on the vehicle by “Of), the origin from which the position is measured (this standard 
designates this by “Wrt"), and the frame in which the observation is made (“ObsFr"). An additional 
challenge is to achieve this specification using just the ASCII set of characters that are used to compose 
variable names. 

Figure 3 shows how the notation used by Stevens and Lewis are mapped into the coordinate system 
components of the variable name schema. Within this standard, point p will be illustrative of the Of 
variable name component, coordinate system M will be illustrative of the Wrt variable name component 
and coordinate system O will be illustrative of the ObsFr variable name component. 



Figure 3 — Mapping Stevens and Lewis notation into variable name components 

Another coordinate system that must be specified is that into which the three vector components are 
resolved in (this standard uses the term 'presentation coordinate system'). This is indicated in the Figure 
3 as the right superscript B, which would indicate which coordinate system is used to resolve the vector 
into three scalar components. 

In order to define position, velocity, acceleration or higher derivative variables (both translational and 
rotational), it is often necessary to specify each of these various coordinate systems The kinematic 
requirements to clearly define these variables are presented below. 

Positions: For positions (including rotational attitudes), the variable name must specify the origin from 
which the position is being measured. The name also must specify the coordinate system in which the 
vector is being resolved. 

Take, for example, the core variable name 

position 

This name alone is meaningless. Therefore, it is necessary to describe what the position is representing: 
positionOf Pi lotEye 

This is still ambiguous as it necessary to specify both the point from which the pilot’s eyepoint is being 
measured and into which coordinate system the position vector is being resolved. 

positionOf Pi lotEyeWrtCm 

This indicates what point is being located relative to what reference point, and therefore a relative position 
vector may be defined in 3-space. Flowever, without knowing in which coordinate system the vector is 
being resolved, any number of coordinate systems could be used. Thus 

bodyPositionOf PilotEyeWrtCm 
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This is a complete and unambiguous variable name representing a three-dimensional position To define 
the name of any of the three body coordinate system axes, we need to append the name of the 
appropriate axis and units of measurement: 

bodyPositionOfPilotEyeWrtCm_f t_X 

This defines a scalar variable representing the X-body axis offset of the eyepoint from the center 
of mass, measured in feet. 

Attitudes: Attitude (rotational position) is the orientation of one coordinate system relative to another; 
therefore, two coordinate systems are required (either explicit or implied) in the variable name to define 
an attitude. These axis systems are specified using the ‘of 1 and ‘wrt’ components. The presentation 
coordinate system is not used because attitude (either as a quaternion, Euler angles, or rotation cosine 
matrix) is not a vector quantity resolved into X, Y, and Z components. 

If the attitude is expressed as a set of Euler angles, the aeronautical convention of yaw-pitch-roll (3-2-1) 
rotation sequence is the default. To specify a different rotation sequence, the sequence should be 
appended to the Euler angle core name, e g eulerAngle313 for 3-1-3 rotations. To avoid confusion, for 
any rotation sequence other than 3-2-1, _First, _second, jrhird should be used for angle selectors 
in lieu Of _Roll, _Pitch, _Yaw. 

For example: 

eulerAngleOf I ssWrtEi_rad_Pi tch 

This variable represents the pitch attitude (rotation about the Y axis) of the user-defined 
International Space Station (Iss) coordinate system relative to the Earth-centered inertial (ei) 
coordinate system, measured in radians. This rotation uses the default yaw-pitch-roll (3-2-1) 
rotation convention 


eulerAngle3 1 30f I ssWr tOrion_rad_Second 

This variable represents the second rotation angle of the International Space Station (Iss) 
coordinate system relative to another user-defined (Orion) spacecraft coordinate system 
measured in radians This variable uses yaw-roll-yaw (3-1-3) rotation convention 


eulerAngleOf ImuWrtBody_rad [_Roll |_Pitch|_Yaw] 

This variable represents the three Euler angles of a user-defined inertial measurement unit (imu) 
coordinate system relative to the body coordinate system. 


eulerAngleOf ImulWrtImu2_rad [_Roll | _Pitch | _Yaw] 

This variable represents the three Euler angles of a user-defined inertial measurement unit 
(imui) coordinate system relative to an imu 2 coordinate system, using the default yaw, pitch, roll 
(3-2-1) rotation convention. 


Derivatives of position (translational or rotational): For variables representing derivatives of 
translational positions (velocities, accelerations and higher derivatives thereof) the observer coordinate 
system must be specified by the naming methodology The observer coordinate system exists in the 
reference frame from which the movement (a velocity, acceleration or higher derivative) is observed (or 
measured). In many cases this is the same reference frame as the relative coordinate system (defined by 
the wrt component) used to specify the position of the object being observed, but in the most general 
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case may be a different frame. The magnitude and direction of velocity (and higher derivatives) varies 
with selection of the observer’s coordinate system since the relative coordinate system may be moving 
relative to the observer’s coordinate system. 

For rotational derivatives, it is unnecessary to specify an observer’s coordinate system, but both 
coordinate frames that describe the rotational derivatives are necessary (both of and Wrt components). 

For example 

eiAngularRateOf IssWrtOrion_rad_s_Y 

This variable represents the angular rate of the ISS coordinate system relative to the Orion 
spacecraft coordinate system. This is the angular velocity vector is resolved to the Earth-centered 
inertial (ei) coordinate system to measure the Y component in that system 

6.3.2 New Position Variables Naming Convention 

The methodology for creating and defining a position variable (linear or angular) that is consistent with the 
requirements of this standard are as follows. 

a) Each variable name may have up to nine components 

b) With the exception of the core name, all components are optional and should only be used if 
required by the application. Units must be specified unless the variable is non-dimensional 
and then the _nd units specification is encouraged. 

The variable name components are listed immediately below. Descriptions of all the components follow in 
this section. 

1 . <variable domain? 

2. _<dynamic equation formulation prefix ? _ 

3 <presentation coordinate system > 

4 <core name ? — the only required component 

5. of <a point for positions or coordinate system for angles, normally on the vehicle > 

If omitted in the variable name, of defaults to the Cm for translational position and the body 
coordinate system for rotational position. 

6. Wrt <”With respect to" a point or coordinate system > 

If omitted in the variable name, wrt defaults to the presentation coordinate system for linear 
positions and to the locally level coordinate system (li) for angular position 

7. ic — initial condition designation 

8 _< units? 

9. _<specific axis of the presentation coordinate system? 

Rarely are all 9 components of a name used. 

For example: 
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universe s eiPositionOfCmWrtEarthlc ft X 



| Units 

Initial Condition Flag 
Relative ref. point/frame 
Reference point or frame 
Core name 
Coordinate System 
Dynamic component 
Domain 

6.3.3 New Velocity, Acceleration or Higher Derivative Motion Variables Naming Convention 

The methodology for creating and defining velocity and acceleration variables (or higher derivatives) 
consistent with the requirements of this standard are as follows: 

a) Each variable name may have up to ten components. 

b) With the exception of the core name, all components are optional and should only be used if 
required by the application. Units must be specified unless the variable is non-dimensional and 
then the _nd units specification is encouraged. 

The variable name components are listed immediately below. Descriptions of all the components follow in 
this section. 

1 . < variable domair» 

2 . _<dyn amic equation formulation pre fix>_ 

3. <pre senta tion coordinate system> 

4. <core name> — the only required component 

5. o f <a point for translation or coordinate system for rotation, normally on the vehicle> 

If omitted, Of defaults to the Cm for translation derivatives and the body coordinate system 
(body) for rotational derivatives. 

6. Wrtc'With respect to" a point, frame or coordinate system> 

The Wrt component (relative coordinate system) may be omitted; if so, the relative coordinate 
system defaults to the presentation coordinate system for translational variables and the locally- 
level coordinate (li) system for rotational variables. 

7 . ObsFr<"Observed From 1 ' coordinate system, only use^ d for tra ns/a i tion a I motion > 

If "ObsFr" is not specified, it defaults to the same coordinate system specified by the relative 
coordinate system (the Wrt component). If the relative coordinate system is not present, ObsFr 
defaults to the presentation coordinate system. 

8 . Ic — initial condition designation 

9. _<units> 

1 0. _<specific axis of the presentation coordinate system> 

Rarely are all 10 components of a name used. 

For example: 
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sensor_s_geVelocityOf IssWrtOrionObsFrGroundStationIc_f t_s_X 


V V 



Core 

name 



Ref. 

pt. /frame 


'V Sr 7 V 


Observer Frame 


Presentation Relative pt./frame 

coordinate system 


Axis 


Dynamic component 


Units 


Domain 


Initial Condition Flag 


6.3.4 New General Variables Naming Convention 

The methodology for defining variables other than positions and derivatives thereof that is consistent with 
the requirements of this standard are as follows. 

a) Each variable name may have up to seven components. 

b) With the exception of the core name, all components are optional and should only be used if 
required by the application Units must be specified unless the variable is non-dimensional and 
then the _nd units specification is encouraged. 

The variable name components are listed immediately below. Descriptions of all the components follow in 
this section. 

1 . < variable domain> 

2. _<dynamic equation formulation prefix>_ 

3. <presentation coordinate system> 

4 <core name> — the only required component 

5. ic — initial condition designation 

6. _<units> 

7. _<specific axis of the presentation coordinate system> 
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For example: 


pr opu 1 s ion_s body Pr oduc t of I ne r t i a I c_k gm2_x z 



Core name 
Coordinate System 
Dynamic component 

Domain 

6.3.5 Adapting the Naming Convention to Hierarchical and Nested Data Representations 

The naming methodology provides all the essential information about a variable in its name. This 
convention is concise for flat data representations (e g. single-datum variables, arrays, common blocks). 
However, the convention can lead to repetition of information if applied to the members of hierarchical 
and nested data structures (e g. classes, structures, records) since structure organization might parallel 
one or more of the variable name components. For example, a developer could create a structure to hold 
all of the variables in an aerodynamics model. The developer could then declare an instance of the 
structure with the name "aero;' 1 the structure name would repeat information in the variable source 
domain component of its member variables. 

An example of a "flat” variable name is: 

aer o_bodyForc e Co efficient_X where "aero" is the variable domain 
Prepending the name of the structure to the standard variable name could result in an expression like the 
one below: 

aer o . aer o_b ody Force Co ef f icient_X 

Such repetition can lead to unnecessarily long expressions. To avoid such repetition, developers may use 
the following guidelines to adapt the naming convention to hierarchical and nested data structures. First, 
when a level of a structure represents an organization of data that is equivalent to a variable name 
component, the developer should use the naming rules for that component to name instances of that 
structure level. Second, if a component of the variable name appears at a higher level or lower level, the 
developer should not include that component in the variable names at the current level. Using these 
guidelines, the example above can be changed to: 

aero.bodyEbrceCoef ficient_X 

If the developer made a further change to represent a vector as a structure and replaced the X , Y, and Z 
variables for the body force coefficient with that structure, the above expression would change to: 

aero .bodyForceCoef fici ent .X 

To meet the intent of the guidelines, it is not necessary that the structure levels address the variable 
name components in the same order that the convention specifies for variable names. The intent of the 
naming convention is to unambiguously identify the information represented by a variable; it is not 
intended to shape data design. Thus, the name components can appear in a different order for a 
hierarchical or nested data expression. For example: 

bodyForce_lbf , aero ,X 

In this example, the data design is such that all the external forces on a vehicle (expressed in body 
coordinates and in units of pound-force) are collected in a structure whose instance is named 
"bodyForce" and whose members represent each generator of force as an instance of a structure 
representing a vector. The variable source domain appears after the core name and units due to the 
chosen data design. Even so, this data expression unambiguously identifies the variable as effectively as 
the equivalent scalar variable name, aero_bodyForce_ibf_x. 
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6.4 Components Used to Create Variable Names 
6.4.1 Variable Domain Component 

This represents the domain in which the variable is calculated In object-oriented design, it could logically 
be the object The domain is normally not included if it (or the object) is the vehicle or aircraft being 
simulated, for example, airspeed. 

In some cases the domain name component only provides background information when exchanging 
models. For example, in one simulation architecture the domain for ambientPressure_N_m2 might be 
“environment” and another architecture the domain might be “atmosphere”. The core component of 
the name is the key. For example: 

environment_ambientPressure_N_m2 in one simulation architecture is identical to 
atmosphere_ambientPressure_N_m2 in an another simulation architecture 

However in some cases the domain component is critical. For example: 

aero_bodyForce_lbf_x and thrust_bodyForce_ibf_x are two different variables, both 
are body axis forces but one comes from the propulsion system model and one from the 
aerodynamic model It is this type of variable where domain must be included 

Some domain examples are presented in Table 2 The domain names presented here are not part of any 
standard; instead they are presented here as examples 


T able 2 — Examples of domain names 


aero 

aerodynamic models 

a i r LaunchedW eapon 

modeling of munitions launched into the air that have their 
own dynamics; includes Missile as a sub-domain 

caut ionAndWarning 

caution and warning simulation 

cockpit 

input/output from/to cockpit instruments and controls 

control Law 

simulation of a control algorithm 

controlLoading 

models of the control system feel 

controlSurface 

simulation of an aerodynamic control effector 

control Sy s t em 

collective model of control laws and control effectors on a 
vehicle 

electrical 

models of the electrical system 

engine (or thrust or 
propulsion) 

thrust generation models 

environment 

atmospheric models (ambient properties, wind, clouds, etc ) 

failureSystem 

failure modeling and fault injection 

f ltDirect 

flight director models 

f uelSystem 

fuel system models 

gun 

model of vehicle mounted guns 

hydraulics 

hydraulic system models 
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landingGear 

landing gear models 

massProperti.es 

tree-based modeling of vehicle mass and moments of inertia 

missile 

missile models Domain could be more specific, for 
example missileAim9x. 

motion 

motion system models and algorithms 

navigationDatabase 

mapping of waypoints, airports, runways, legs, procedures, 
and navigation transmitters (all of which are subdomains) 

navigationReceiver 

modeling of signal-based navigation sensors 

navigationTransmitter 

modeling of navigation signal generators (e.g. radios, GPS) 

parachute 

parachute models 

propulsion 

models the collection of thrust generators (engines) on a 
vehicle 

radar 

models the radar system. Domain could be more specifc, 
for example radarApg7 9 ) 

relGeom 

relative state (position, velocity, and acceleration) of each 
vehicle to each other vehicle 

sensor 

models of sensors 

sensorSystem 

modeling the collection of sensors on a vehicle 

sim 

Domain encompassing control of the simulation, 
configuration of a simulation run, control of mathematical 
techniques such as integration type, etc 

vehicle 

modeling of the vehicle as a cooperating system of other 
domain models 

weaponSystem 

collective model of guns and air-launched weapons on a 
vehicle 

wheel 

landing gear wheel models 

world 

world model (shape, dynamics, and reference time(s) plus 
navigation database and environment domains) 

universe 

domain encompassing world, vehicle, and relative geometry 
domains 


NOTH Users may add as many domains as needed to clearly identify the variable 
Variable name examples using “aero” and “thrust” include: 

a) aero_bodyForce_lbf_X 

b) thrust_bodyForce_lbf_X 

c) aero_bodyForceCoef f icient_X 
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d) thrust . bodyForceCoef f icient_x — this is an example of thrust as a structure 

e) thrust . bodyForceCoef ficient (X) 

6.4.2 Dynamic Equation Formulation Prefix Component 

The dynamic equation formulation prefix is used to identify the most important dynamic variables in the 
simulation, the states (x) and their derivatives (x), inputs («), outputs (y), and disturbances (w) as 
presented in the equation below. These variables characterize the resultant dynamic response of a 
vehicle as shown in the equations below In addition to these variables, the standard allows the prefix to 
separately designate simulation control variables (c). Simulation control variables are used to modify the 
behavior of the model during simulation and are not part of the vehicle model, while inputs («) are 
variables that represent the inputs to the vehicle model which may include pilot control positions Finally, 
in simulation or analysis where noise and environmental disturbances are modeled, the disturbances (w) 
are the final component in the simulation of the total system dynamics. 


x = Mx(f),u(f),w(f)} 
y = fj{x(f),o(f)} 

The prefix shall be separated from the body of the variable by an underscore (_) and from the domain 
name by an underscore (or a period if preceded by a member of a structure or class) The leading 
underscore is not permitted if a domain name is not present. 

6.4.2. 1 Identification of Simulation Model States and State Derivatives 

The states (x) and state derivatives (dx) are those variables that make the simulation dynamic and are the 
key variables in a flight simulation model Basically, any variable that is mathematically integrated is a 
state derivative. The result of integration of a state derivative over a period of time is a change in the 
value of the corresponding state over that time, This is true for any integration in a simulation. If the user 
controls the changes in all the states, they control the trajectory of the simulated model The time histories 
of the states and inputs are the key variables required for validation. All outputs are computed directly or 
indirectly from states and inputs 

The formulation of the equations of motion and the model itself determines what variables are states. This 
naming convention is not meant to standardize on any variable as a state, but allows the simulation 
engineer to explicitly identify states in the model implementation, making it easier to document and 
exchange the models. 

Examples: 


x_bodyVeiocityWrtEi_f t_s_x x_ prefix indicates that this variable is a state 

dx_bodyAccelerationWrtEi_ft_s2_x dx_ prefix indicates that this variable is a state 

derivative 


6.4.2.2 Identification of Simulation Model Inputs 

The simulation model inputs («) are those variables that provide the pilot or autopilot inputs to the vehicle 
model These are also called controls in many references. As with the states and state derivatives, the 
model inputs are key variables for validation. All model outputs are computed directly or indirectly from 
model states and inputs. 

The formulation of the model itself determines which variables are inputs This naming convention is not 
meant to standardize on any variable as an input, but allows the simulation engineer to explicitly identify 
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them, making it easier to document models, exchange them, and verify them 
Examples: 


u_con t rol Sur f a ce Pos_deg_a vgAi 1 e ron 

u prefix indicates that this is a model 

input 

controlLaw u controlSurfacePos deg avgAileron 

same variable name with domain 
prefix 

controlLaw . u_controlSurfacePos_deg_avgAileron 

same variable name in a hierarchical 
architecture 

u_pi lot Control Pos_r ad_l ong 

Another example of the longitudinal 
pilot input 


6.4.2.3 Identification of Simulation Model Disturbances 

The disturbances (w) are those variables that provide environmental disturbances or system noise to the 
simulation models. 

Disturbances may be inserted into the vehicle model, environment, or equations of motion, depending 
upon implementation schemes This naming convention is not meant to standardize on any variable as a 
disturbance, but allows the simulation engineer to explicitly identify disturbances, making it easier to 
document models, exchange them, and verify them 

Examples: 


w_bodyAngularRateTurbulenceWrtGe_deg_s_Yaw 

w_ prefix indicates that this variable 
is a disturbance 

envi ronment_w_bodyAngularRat eTurbul enceWr tGe_deg_s_Y aw 

same variable name with domain 
(environment) added 

envi ronment . w_bodyAngul a rRateTurbul enceWr tGe_deg_s_Yaw 

same variable name in a hierarchal 
architecture 


6.4.2.4 Identification of Simulation Model Outputs 

The simulation model outputs (y) are those variables that are the outputs of the physics of the simulation 
models as formulated by the state equations This is meant to assist in the specification of the state 
equations, mainly to help simplify model exchanges between simulations used for analysis and those 
used for real-time man in the loop or hardware in the loop simulations 

Example: 


y lef tHorizonalActuatorRamPosition deg 

y prefix indicates that this variable is a model 


output. 
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6.4.2. 5 Identification of Simulation Controls 

The simulation controls (c) are those variables that provide the simulation operator control of the 
simulation [not to be confused with simulation model inputs («)]. The simulation controls should not affect 
any vehicle states, state derivatives or outputs 

The software and hardware architecture of the simulation determines what variables are simulation 
controls. This naming convention is not meant to standardize on any variable as an control, but allows the 
simulation engineer to explicitly identify simulation controls Clear definition of simulation controls makes 
validation of a simulation much easier after a model is exchanged. 

Examples: 


c_simDuration_s 

c prefix indicates that this variable is a simulation control 

c_deltaTime_s 

another example 

sim_c_deltaTime_s 

same variable name with domain added 

sim. c_deltaTime_s 

same variable name in a hierarchal architecture 


6.4.3 Presentation Coordinate System Component 

This is the coordinate or reference system to which the variable is referenced or in which it is measured (it 
is indicated by the "B" in Figure 3). Table 1 specifies the standard coordinate system abbreviations that 
should be used. If no coordinate system pertains to the variable or the core variable name needs no 
reference system to be unambiguous (e g Airspeed), this part of the variable name may be omitted. 

6.4.3. 1 Conventions Used 

Earth fixed and local coordinate systems by convention use X, Y, Z, for both translation and (X, Y, Z), 
(Pitch, Roll, and Yaw), or (First, Second, Third) for rotation axis indices. The origin and attitude of local 
coordinate systems (flat Earth for example) may be user defined (such as N, E, D) Local coordinate 
systems are meant for runway, test range, target reference, navigational aids, etc. 

6.4.3.2 Variable Name Examples 


The following variable names are provided as examples. 


xbodyAngula r Ra t e_r ad_s_Rol 1 
x_bodyAngularRate_rad_s . Roll 
x_bodyAngularRate_rad_s_X 

These are all equivalent variable names where 
body is the coordinate system and roll is the 
specific axis in the body axis system, roll 
indicating angular motion about the longitudinal 
axis relative to the locally-level frame (wrt 
defaults to locally-level for rotational variables). 

NOTE In this example the variable is designated 
as a state. 

x_bodyVelocityWrtEi_m_s_X 
x_bodyVelocityWrtEi_m_s . X 

These represent translational inertial velocity in 
the body coordinate system along the longitudinal 
axis (the translational variable analogous to the 
rotational variable above). 

These are all equivalent variable names 
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g eV e loc i t y_m_s_Y 

This represents a translational velocity with ge 
specified as the coordinate system and Y as the 
specific axis. This non-inertial velocity of the CM 
is relative to and measured in the geocentric 
earth-fixed (ge) coordinate system 

bodyTurbul enceVeloc i tyWr tGe_f t_s_Z 
bodyTurbulenceVeloci tyWrtGe_f t_s 1 3 ] 
bodyTurbulenceVelocityWrtGe_f t_s. Z 

These are all equivalent variable names where 
body is the coordinate system and Z is the 
specific axis in the body coordinate system, z 
indicating vertical translational motion. Also 
illustrated as a vector and structure 

runway22VelocityOfLef tWheelWrtTd_f t_s_Z 

Here runway22 is the coordinate system (user 
defined) and z is the specific axis, also 
indicating translational motion. Lef twheel is the 
point on the vehicle and Td (touchdown point) is 
the reference point. 

bodyAccelOfPilotEyeWrtEi_m_s2_Y 

Here body is the coordinate system and y is 
the specific axis, also indicating translational 
motion Design pilot eyepoint is the point on the 
vehicle. 

x_e i Ve loci ty_f t_s_X 

This is a case where the equations of motion are 
formulated such that the variable is a state, 
resolved in the earth centered inertial (ei) 
coordinate system 

e iVeloc ity__f t_s_X 

This is a case where the equations of motion are 
formulated such that the variable is not a state 

x UVelocity ft s X 

Locally Level coordinate system 

x_f e Ve loci ty_f t_s_X 

Flat Earth coordinate system 

bodyAngul a rRa t e_rad_s_Pi t ch 


bodyAngul a rRate_rad_s_Roll 


bodyAngul a rAcce l_r ad_s 2_Yaw 



Note that the standard allows (X, Y, Z) or (Roll, Pitch, Yaw) or (First, Second, Third) as selectors for 
rotational positions and derivatives, since that is widely conventional However, since the overall objective 
of the standard is to form a framework for clear communication between simulation facilities, the use of X, 
Y, Z selectors is acceptable. The appropriate core variable name shall be used to indicate whether the 
variable is a translational or rotational variable. 

6.4.4 Core Variable Name Component 

This is the most specific (hence core) name for the variable All variable names shall include this 
component of the name 

Core variable name examples are as follows 

• velocity convention for velocities 

• anguiarRate convention for angular rates 
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The 


accel 

angular Accel 

pilot Cont r ol Pos 
pilotControlRate 
pilotControlAccel 
pilotControl Force 
copilot ControlPos 
copilotControlRate 
copilot ControlAccel 
copilot ControlForce 
controlSurfacePos 
controlSurfaceRate 
control Surf aceAcce 1 
controlSurf aceHingeMoment 
lif tCoeff icient 
dragCoef f icient 
forceCoeff icient 
turbulenceVelocity 
angleOf Attack 
angleOf Sideslip 
cosineOf AngleOf Sideslip 
thrust 
torque 

ollowing extended variable names are provided as examples 
x_bodyAngul a r Ra t e_r ad_s_Rol 1 
bodyTurbulenceVelocityWrtGe_ft_s_X 
geVelocity_f t_s_Z 
geVelocity_m_s_Z 
pilotControl Pos_deg_long 
pilotControlPos_deg_lat 
pilotControlRate_deg_s_pedal 
pilotControlAccel_deg_s2_long 


convention for translational accelerations 
convention for angular accelerations 
conventions for pilot controls 


conventions for pilot controls 


conventions for control surfaces 
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copilotControlPos_deg_long 

copilotControlPos_deg_lat 

copilotControlRate_deg_s_long 

copilotControlAccel_deg_s2_long 

controlSurfacePos_deg_elevator [number of surfaces] 

controlSurfaceRate_deg_s_rudder [number of surfaces] 

controlSurfaceAccel_deg_s2_aileron [number of surfaces] 

controlSurfaceHingeMoment_f tlbf_canard [number of surfaces] 

angleOf Attack_rad 

angleOf Sideslip_deg 

cos ineOf Angl eOf Sideslip 

cont rol Sur f acePos_deg_ai 1 eron 

totalPressure_N_m2 

ambientPressure_N_m2 

totalLif tCoef f icient 


• aeroBodyForceCoeff icient 

• aeroBodyForce_lbf 

• aeroBodyForce_N 

• thrustBodyForce_N 

6.4.5 Reference Point or Coordinate System (“Of”) 

This component of the name is designed to clarify positions, velocities and accelerations and is normally 
omitted if the variable is not a position, velocity or acceleration. However, it may be used for any variable 
if desired This component describes which point or object that is being specified “of" is used to specify 
the point or object (this is point p in Figure 2) 

For those who prefer shorter variable names, the standard adopts the convention that if the point or 
location on the vehicle is the center of mass for translational motion variables, then the reference point 
may be omitted For rotational motion, the default reference coordinate system is the body axis 
coordinate system 

Reference points may be defined by the user and depend on the object the variable is describing. 
Examples of reference points are as follows. 


• of Cm 

• Oflmu 

• OfSensor 

• OfMrc 


the center of mass is the default point, so “ofcm” is normally omitted in any 
variable name. 

or ofimul, ofimu2, OfimuLtn200, etc. 
or OfRadar, OfFlir, Of RadarApg67 , etc. 
for moment reference center 
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• of PilotEye for the pilot eye point 

• ofRadAit for radar altimeter 

• ofTerrain a normal Earth-fixed coordinate system with origin where the vehicle nadir 

intersects the terrain 


The following variable names are provided as examples, 


bodyPositionOf ImuWrtCmm [3] 

This three-element vector locates the Imu relative 
to the CM in the body axis coordinate system. 
Note that [3] indicates (for this example) that the 
referenced variable is a three-element vector. 

body Pos i t i onWr 1 1 mu_m [ 3 ] 
bodyPositionOf CmWrtImu_m [3] 

Both of these vector names refer to the same 
quantity, it is the opposite of the vector above 
(they locate the CM relative to the Imu). In the first 
name “of cm” is omitted since it is default. 

eulerAngleOf ImuWrtBody_rad [3] 

This is the angular equivalent of the first variable 
above. The 3-2-1 rotation convention is implied 

x bodyAngularRateWrtEi_rad s[3] 

Here element 1 would be about the X-axis (roll), 
element 2 would be about the Y-axis (pitch) and 
element 3 would be about the Z-axis (yaw). These 
are inertial rates since they are measured with 
respect to the Earth inertial (Ei) coordinate 
system. 

body Ve loci ty Wr t Ai r_f t__s_X 

Of Cm is implied 

bodyVelocityOf CmWrtAir_f t_s_X 

Same meaning as above 

body Ve loci ty W r t E i__f t_s_X 

Inertial velocity of the CM along the X-body axis 

body Ve loci ty Wr t E i_m_s_X 

Inertial velocity of the CM along the X-body axis in 
SI units 

heightOfCmWrtTerrain_f t 

of Cm may be omitted since it is the default 

he ightOf RadAl tW r tTer ra in_f t 


heightOf TerrainWrtWgs 8 4_f t 

Height of nadir intersection with terrain above the 
reference ellipsoid 

bodyPositionOf Pi lot Ey eWr t Cm_f t_X 


geLongi tudeRa teOf I mu_deg_s 


longitudeOf ImuWrtGe_deg 
geLongitudeOf Imu_deg 

These are the same scalar quantity. 

bodyAccelOfPilotWrtEi_ft_2 [3] 

Inertial acceleration vector in the body axis 


6.4.6 Component Indicating Relative Reference Point or Relative Reference Coordinate System 

The relative reference component is generally used in conjunction with the “reference point or location on 
the vehicle” component described in section 6,4.5. It is primarily used in variables describing position, 
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velocities and accelerations This component defines the reference that the motion or position is relative 
to. This component, preceded by “Wrt” (with respect to) in the variable name, is the equivalent of 
coordinate system M in Figure 2, as noted in Figure 3. 

For position variables, Wrt refers to the reference point for linear positions. For angular positions, Wrt 
refers to the relative coordinate system. For derivatives of position (velocities, accelerations, etc.) Wrt is 
used to define relative motion of two objects. 

If “Wrt" is omitted then the default points or relative coordinate systems are 

the presentation coordinate system for linear positions and translational motion. For example, 
bodyPositionOfImu_m[3] . Here WrtBody is implied 
the locally level coordinate system specified for rotational variables. For example: 
eulerAngleOfImu_rad[3] . Here “WrtLl” is implied. 

Note: Since for translational motion the “Wrt” defaults to the presentation coordinate system the variable: 

bodyVelocity_f_s_X 

while a valid variable, has little usefulness because, fully enumerated is: 

bodyVelocityOfCmWrtBodyObsFrBody_f_s_X 

Body velocity of the Cm with respect to the body is virtually always near zero. It would only represent the 
movement of the Cm within the body, due to cargo shift, fuel burn, etc. It would not represent velocity of the 
Cm with respect to a coordinate system outside the aircraft. 


Examples of reference points are as follows: 


Wrt Cm 

this is commonly used to clarify definitions of positions within the vehicle 

WrtEi 

identifies a variable that is referenced to inertial space 

WrtMrc 

moment reference center 

WrtTgt 

aim point 

Wrt Impact 

the desired weapon impact point 

WrtAir 

the local atmosphere, used to define air-relative (or wind-relative) motion 

WrtMeanSL 

mean sea level 

WrtGe 

the geocentric Earth fixed coordinate system 

WrtGround 

a normal Earth-fixed coordinate system with origin where the vehicle 
nadir intersects the smooth surface of the Earth 

WrtTerrain 

a normal Earth-fixed coordinate system with origin where the vehicle 
nadir intersects the terrain 


The following linear and angular position variable names are provided as examples: 


body Pos i t ionOf I muW r t Cm_m ( 3 ] 


This vector locates the Imu relative to the CM in th 
body axis coordinate system. 

WrtCro may be omitted since CM is the defat 
reference point for linear position measurements 
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eulerAngleOf I mu_rad [3] 
eulerAngleOf I muWrtLl_rad [3] 

This is the angular equivalent of the first variable 
above In the first variable ’’Wr-tLl" is omitted since 
the locally-level coordinate system is the default 
relative coordinate system for angular positions 

eulerAngleOf I muWrtBody__rad [3] 

This is a vector representing the alignment of the 
IMU with respect to the aircraft body 

eulerAngleOf ImulWrtImu2_rad [3] 

This is a vector representing the attitude of Imul 
relative to Imul , 

bodyPositionOfPilotEye_f t [3] 

wrtBody is implied since the Wrt defaults to the 
presentation coordinate system. Since the Body 
coordinate system origin is at the Cm, this variable 
represents the position of the Pilot design eye with 
respect to the Cm (+ = eye fwd: right: below Cm) 

geLongitudeOf Imu_deg 

WrtGe is implied (since ge is the presentation 
coordinate system) 

geLong i tude_deg 

of cm is implied when not given 

bodyPositionOf CmWrtMrc_f t [3] 


heightOf RunwayWr tMeanSL_f t 



6.4.7 Component Indicating Observer’s Coordinate System (Vehicle translational motion 
variables only) 

For variables representing derivatives of linear positions (velocities, accelerations and higher derivatives 
thereof), the observer's coordinate system (indicated by ObsFr for “Observed From")) must be specified. 
The observer’s coordinate system is in that reference frame from which the movement (a velocity, 
acceleration or higher derivative) is observed or measured In many cases this is the same reference 
frame as the relative coordinate system (given by Wrt) but in the most general case it may be a different 
frame The magnitude and direction of velocity (and higher translational motion derivatives) differ 
depending on the motion of the observer’s coordinate system. This is the coordinate system shown as the 
upper left superscript in the Stevens and Lewis convention shown in Figure 3 and is illustrated by 
coordinate system O in Figure 2 

It is conventional to omit the observer's coordinate system when it is the same as the reference (Wrt) 
coordinate system. As noted in Section 6.4.6, when the Wrt coordinate system is omitted it defaults to the 
presentation coordinate system for translational variables, so when both the wrt (reference) and the 
observer’s (ObsFr) coordinate systems are omitted, the default observer’s coordinate system is the 
presentation coordinate system. 

It is neither necessary nor appropriate to specify the observer’s coordinate system for rotational motion 
variables as rotations are invariant with the location of the observer. 

Some examples are: 

geVelocity_f t_s_X 

Velocity of the ownship center-of-mass in the geocentric Earth coordinate system (velocity along 
the GE X-axis) Note that the reference point (Of), relative coordinate system (wrt) and observer’s 
coordinate system (ObsFr) default to the velocity of the center of mass with respect to and 
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observed from the geocentric Earth-fixed coordinate system since they are omitted. 
geVeloc ityOf CmWr tGeObsFrGe_f t_s_X 

This is the same variable as the previous one with the reference point (ofcm), relative coordinate 
system (wrtGe) and observer coordinate system (obsFrGe) all explicitly specified (they are not 
required since they are the defaults). 

bodyAccelWrt E i_f t_s2_X 

Acceleration of the vehicle center of mass relative to and observed from the Earth-fixed inertial (El) 
coordinate system and presented in the body axis coordinate system (acceleration along the body 
X-axis). Naming convention components that can be implied are omitted 

bodyAccelOf CmWr tEiObsFrEi_f t_s2_X 

This is the same variable as the previous one with the reference point, relative coordinate system 
and observer coordinate system all explicitly specified 

bodyVelocityWrtAir_ft_s_X 

This is the air-relative velocity of the CM expressed in body coordinates; the obsFr component is 
omitted to indicate that the observer’s coordinate system is in the same frame as the steady state 
air mass reference frame (Air). 

bodyVeloc i tyOf CmWr t Ai rObsFr Air_f t_s_X 


Same as the variable above, fully expressed 


bodyPositionOfPilotEyeWrtCm ft X 


The position of the pilot’s eyepoint relative to the vehicle center-of-mass along the body X-axis. 
Note that the sign convention is clear: since the X-axis origin is at the center of mass, and is 
positive forward, the pilot’s eyepoint position is positive when forward of the center of mass 


bodyPositionOfPilotEyeWrtMrc_f t_X 


The position of the pilot's eyepoint relative to the moment reference center along the body X-axis. 
Note that the sign convention is clear: since the body X-axis origin is at the center of mass, and is 
positive forward, the pilot's eyepoint position is positive when forward of the MRC. 


bodyAccelOf PilotWrtEi_f t_s2_ [3] 


This represents the inertial acceleration of the pilot, resolved into the vehicle’s body axes The 
obsFr component is omitted, implying the motion is observed from the wrt coordinate system 
(here, Earth Inertial). 


bodyAccelOf Pi lotWrtEiObsFrE i_ft_s2_ [3] 


Same as above. ObsFr explicitly stated. 


bodyVeloc i tyWr t E i_f t_s_X 


Inertial velocity of the CM along the X-body axis 


body Ve locityOfCmWrtEiObsFrEi_f t_s_X 


Same meaning as the previous variable, fully 
expressed 


runway22VelocityOfLef tWheelWrtTdObsFrTd_f t_s Z 


This is the velocity of the wheel relative to the TD point observed from the TD coordinate system 
The user must explicitly define the TD coordinate system, but logically it is in an Earth-fixed 
reference frame, probably with the origin at the desired touchdown point and aligned with the 
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runway. 


runway 2 2Ve loc i tyOf Lef twhe elWrtTd_f t_s_Z 


This is the same variable as above, since omitting ObsFr implies it is the Wrt coordinate system 


veloci tyW r tGroundf t_s 


This scalar variable is commonly known as groundspeed 


6.4.8 Component Indicating Initial Variables 

A convention proposed by this standard is adding "ic" to the end of any variable name, before any units, 
to designate that the variable is an initial condition specification. This can be added to virtually any 
variable without an underscore separator, conceptually creating a constant, for example: 

1. x_bodyVelocityWrtEiIc_rad_s_X 

2. grossWeightIc_N 

6.4.9 Units Suffix 

The suffix is used to describe the units of the variable The convention for the suffix is simple and is 
followed for all variables. When exchanging simulation models, the units of all variables must be specified 
and this is the mechanism to do so. This will also allow the user, the programmer, and the reader of the 
code to check for homogeneity of the units and is self-documenting in this respect Therefore, units shall 
be included in all variables except variables that are non-dimensional If required for clarity, “nd” may be 
used in the units suffix to indicate a non-dimensional variable. Including units has the added advantage of 
making this standard consistent and acceptable in countries utilizing the international system of units. For 
example, airspeed is equally acceptable as a standard both for the U S. system of units and the 
International system of units. 

The standard uses an underscore (_) to separate the numerator from the denominator an analogy to 
exponential notation for the specification of units. For example, the unit expression for cubic feet per 
second squared (for example) would be ft’s ’. Eliminating the superscripts leaves ft3s-2 Separating 
the numerator from the denominator results in ft3_s2, since the negative sign in the denominator 
exponential term is dropped. 

With few exceptions, only base units are supported; it is not allowed to have, for example, milliseconds 
(ms). Here the proper use would be to express that variable in seconds. 

Further examples are as follows: 

1 trueAirspeed_f t_s for feet per second (ft/s) 

2. t rueAi rape ed_m_s for meters per second (m/s) 

3. t rueAi rape ed_kt for knots (nautical miles per hour) 

4 bodyAccelWrtEi_f t_s2_x for feet per second squared (ft/s * 1 2 3 ) 

The suffix shall be separated from the body of the variable name by an underscore. The standard unit 
notations are given in Table 3; SI units and standard abbreviations are included where available 
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Table 3 — Abbreviation for units-of-measure in standard variable names 


Time 

second 

a 

S 

minute 

min* 

hour 

h e 

Lenqth 

inch 

inch 

foot 

ft 

meter 

m* 

nautical mile 

nmi 

statute mile 

smi 

kilometer 

km 

centimeter 

cm 

millimeter 

mm 

astronomical unit 

e 

ua 


volt, alternating] current 

Vac 0 

current (ampere) 

A a 

frequency (hertz) 

Hz" 

inductance (henry) 


capacitance (farad) 

~P~ 

charge (coulomb) 


conductance (siemens) 


resistance (ohm) 

ohm 


Other 

pressure, stress (pascal) 

Pa” 

standard gravitational 
acceleration unit 

g 

luminous intensity (candela) 

cd" 

luminous flux (lumen) 

lm 6 

illuminance (lux) 

lx° 

amount of substance (mole) 

mol a 

magnetic flux density (tesla) 

T d 

magnetic flux (weber) 

Wb B 

radioactive activity 
(becquerel) 

Bq° 

absorbed dose (gray) 

Gy” 

dose equivalent (sieved) 

Sv B 

nautical mile per hour 

kt 

non-dimensional 

nd 


Force 

pound force 

lbf 

Newton 

N b 

kilogram force 

kgf 

Mass 

kilogram 

kg" 

pound mass 

lbm 

slug 

slug 

Solid Angle 

steradian 


Plane Angle 

degree 

deq 

radian 

rad° 

revolution 

rev 


Temperature 

degrees Rankine 

dqR 

degrees Celsius 

dgC° 

degrees Fahrenheit 

dqF 

Kelvin 

dgK c 


Power, energy, work, heat 

energy (British 
thermal unit) 

btu 

energy (erg) 

erg 

energy (calorie) 

Cal 

energy (joule) 


power (horsepower) 

Hp 

power (watt) 


Electrical units 

potential (volt) 

v" 

volt, direct current 

Vdc° 
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Notes: 

a. SI base unit (reference ISO 80000-1:2009, §6.5.2) 

b. SI derived unit (reference ISO 80000-1 :2009, §6.5.3) 

c. SI base unit with modified abbreviation 

d. SI derived unit with modified abbreviation 

e ISO recognized non-SI unit (reference ISO 80000-1 :2009, §6 5 6) 

6.4.10 Units-agnostic models 

Some models have identical formulations whether the system of measurement is the SI system or the 
U S customary system The units of the model’s outputs depend only on the units of the values that are 
provided as inputs. These “units-agnostic" models can be reused in simulations with few or no 
conversions performed on inputs or outputs by the host simulation. To allow the exchange of units- 
agnostic models, the standard provides a set of abbreviations for generic units that represent the base 
units that differ between SI and U S. customary system, namely length, mass, and temperature 


Unit 

Abbreviation 

length 

L a 

mass 

M a 

temperature 

dgT° 


Notes: 

a ISQ base unit (reference ISO 80000-1 2009, §3.7) 
b ISQ base unit with modified abbreviation 

The two systems of measurement use the same unit for time (second) The U S customary system does 
not define units for the base quantities of electric current, luminous intensity, and amount of substance; 
the SI units (see ISO 80000-1:2009) fill this omission. Therefore, generic units are not required for time, 
electric current, luminous intensity or amount of substance; the SI unit for these quantities is used for 
variable names in unit agnostic models 

Examples of variable names using generic units: 

• bodyForce_ML_s2_Z 

• bodyVelocityWrtGe_L_s_X 

• thermalConductivity_ML_s3dgT 

Note that the last variable, thermal conductivity, would normally be published in SI units of W/(m-°K) 
[equal to kg-m/( s 3 -K )] with a conversion factor to the typical English units of BTU/(hr-ft-°F), neither of 
which equals the English unit substitution in the variable name of slug-ft/(s 3 -‘R). So, a host simulation 
based on U S. customary units would need to convert the published value to slug-ft/(s 3 -°R) before passing 
the value to the model. (A unit conversion is not required in a host simulation based on SI units ) If this 
model were originally developed for that host simulation, the model developer would likely have placed 
the necessary conversions from BTU and hours (or from the published SI value) within the model; 
however, by formulating the model as unit agnostic, responsibility for conversion has been moved to the 
host simulation The thermal conductivity example illustrates how a unit agnostic model may still require 
conversion of inputs or outputs by the host simulation 

6.4.1 1 Component Indicating Specific Axis, Coordinate Component or Reference 

The last component is the specific axis, coordinate component or reference used within the coordinate 
system (coordinate systems are defined in Section 5). It may also indicate elements of vectors and 
arrays. It is separated from the units by an underscore (_). As can be seen in the examples, this 
component is appended last to keep the naming convention consistent for variables that are scalars or 
vectors. If the coordinate system is included in the name, the specific axis or reference should also be 
included. 
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Standard axes selector sets are: 

a) (X, Y, Z) for linear/translational motion, 

b) (X, Y, Z), (Roll, Pitch, Yaw) or (First, Second, Third) for angular motion. 

When the specific axis or reference can logically be a vector or an array, the vector or array component 
may be convenient for a specific implementation. When coordinate system vectors are used, a right- 
handed triad in order (X, Y, Z) shall be used to avoid confusion. Due to differences between 0- and 1 - 
based array indexing in various implementation languages, use of numerical indices is discouraged 

In the following examples, z would be defined as a constant of either 2 or 3 depending on the 
implementation language array indexing convention 


Variable name examples: 


x_bodyAngula r Ra t e_rad_s_Rol 1 
x__bodyAngularRate_rad_s [Roll] 
x_bodyAngularRate_rad_s . Roll 

Here body is the coordinate system and 
roll is the specific axis in the body coordinate 
system, roll indicating angular motion. 
Examples show alternate scalar and vector 
implementations and implementation as a 
structure. 

NOTE In this example the variable is 
designated as a state 

bodyTurbul enceVe loc i t yWr tGe_f t_s_Z (standa rd) 
bodyTurbulenceVelocityWrtGe_f t_s [ Z] 
bodyTurbul enceVelocityWrtGe ft s.Z 

Here body is the coordinate system and : 
is the specific axis in the body coordinate 
system, z indicating vertical translational 
motion 

g eV e loc i t y_m_s_Y 

Here ge is the coordinate system and Y is 
the specific axis, also indicating translational 
motion. 

runway22VelocityOf Lef tWheelWrtTd_f t_s_Z 

where runway22 is the coordinate system 
(user defined) and z is the specific axis, 
also indicating translational motion. 
Lef twheel is the point on the vehicle and 
Td (touchdown point) is the reference point. 

bodyAccel0fPilotEyeWrtEi_m_s2_Y 

Here body is the coordinate system and y 
is the specific axis, also indicating 
translational motion. Design pilot eyepoint 
location is the point on the vehicle. 

bodyProductOf Inert ia_slugf 2_YZ 

Here, _yz selects the element in the second 
row and third column of the inertial matrix 


6.5 Additional Discussion 

Very rarely, if ever, are all 10 components of a name used. In the case of 

x_bodyAngu 1 a r Ra t e_r ad_s_Rol 1 

the following five components were used: 

1 . prefix (x J indicating that in this formulation of the equations of motion this variable is a state, 
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2. coordinate or reference system (body), 

3 core name (AngularRate), 

4 units suffix (rad_s), for radians per second 
5. specific axis or reference (Roll) 

In this case “variable source domain” was omitted because x_bodyAngularRate_rad_s_Roll is a 
single quantity defined by the laws of physics; there should not be separate body rates associated with 
aerodynamics and a propulsion system If, however, the user wanted to have a multi-body simulation, 
logically the “variable source domain” could be used to discriminate between different elements of the 
body, or, perhaps more logically, an array or structure would be used to define different elements in a 
multi-body or flexible structure problem. 

The of, wrt, and obsFr were omitted because the variable is describing motion about (of) the CM and 
relative to the locally-level coordinate system Recall that wrt defaults to the locally-level frame for 
rotational motion and rotational motion variables do not allow specification of an observer's (obsFr) 
coordinate system. 

An ic flag is not present, indicating that this variable does not specify an initial condition 

The intent of these conventions is to provide clear communication when exchanging models, not to force 
the universal use of these variable names x_bodyAnguiarRate_rad_s_Roii is intended to be a 
clear, brief, unambiguous name for the variable. 

6.5.1 Discarded Conventions and Reasons 

One convention considered eliminated the units suffix when the units were from a standard set, but this 
concept was discarded since always having the units associated with the variable name should help the 
developer maintain consistent units in the simulation and to reduce programming errors due to improper 
mixing of units. Consistent application of units in variable names should also reduce the software 
maintenance effort when a subsequent developer is trying to understand the code to make bug fixes, 
implement enhancements, or reuse the code 

6.5.2 Relationship with Markup Grammar, DAVE-ML 

At present, this variable naming convention is targeted for use with the DAVE-ML XML grammar for 
model exchange (see Section 7). In DAVE-ML, the dynamic equation formulation prefix and the units 
suffix are stored as separate components (attributes or child elements) of the variable definition. Thus, 
including these in a variable name encoded in DAVE-ML would be redundant and a potential source of 
conflicting information. 

The recommended practice is therefore to strip these components (the prefix and suffix) from the variable 
name when encoding to DAVE-ML, and reinsert them into the variable name if code or model data is 
generated from the DAVE-ML Following this convention has two advantages. 

1) The DAVE-ML grammar does not enforce naming rules; for those variables that do not conform to 
the naming convention and therefore do not have state/state derivative designation or units, 
DAVE-ML encourages the inclusion of this information to assist with the clear documentation of a 
model. 

2) The convention allows XML processors to adopt the practice of automatically stripping and 
adding the prefix and suffix to the variable names, reducing the possibility of human error during 
translation. 

6.6 Standard Variable Name Table Example 

Using the conventions discussed above, a set of standard variable names has been created These are 
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presented in Annex A. An excerpt of Annex A is given in Table 4 for illustrative purposes 

Interpretation of the standard variable name annex is best given by example. Table 4 presents the 
standard variable defining the roll Euler angle, its axis system and positive sign convention (positive is 
RWD, or right wing down). Four name examples are provided. The table includes: 

1) The symbol for that variable, <I> 

2) The short name, phi - the short name is included to accommodate standard variable definitions 
for legacy compilers with significant name length restrictions 

3) One or more full names using the standard units conventions — generally, one full name with 
American convention units and one with SI units. Refer to section 6 for a list of the standard units 
and their abbreviations. 

NOTE: While the variable naming convention described in Section 6 encourages the use of the 
<variable domain> component, this Annex does not include variable domains as part of the 
normative standard names. This is because the variable domain is normally dependent upon the 
simulation architecture, and as such is immaterial to the exchange of a simulation model unless 
the exchange is between facilities with similar architectures. 

NOTE: Any suitable units may be used. In the example for eulerAngle_Roll both the _deg for 
degrees and the _rad for radians are given. The “Full Variable Name" column does not 
necessarily provide all acceptable units for each variable 

4) A description of the variable, if applicable should always specify the coordinate system Refer to 
section 5 for a description of the standard coordinate systems. 

5) The POSITIVE sign convention of the variable — RWD indicates that positive 
euierAngie_Roii is right wing down. (See section A.2.1 for a list of sign convention acronyms) 

6) Minimum value, normally only specified for angles 

7) Maximum values of the variable, normally only specified for angles 
In addition this example also illustrates the pitch and yaw Euler angles. 

Since roll, pitch and yaw may also conveniently be expressed as an array, the first variable name in Table 
4 is the standard definition of the Euler angle array Again, eulerAngle_rad ( 3 ) would be the standard 
array using radians as the units and is fully compliant with the standard. 

Euler angles are used in virtually any air vehicle simulation. While normally the coordinate system would 
be included in the name, it was not included due to the universal definition of Euler angles. A more 
rigorous name would be HEulerAngleOfBodyWrtLl_deg[3]which expresses all the defaults ( the 
variable is the Euler angles of the body with respect to the locally level [11] coordinate system and is 
presented in [or measured in] the locally level coordinate system) Aircraft simulations typically use Euler 
angles defined via the 3-2-1 angle rotation sequence (yaw, pitch, roll); other rotation sequences may be 
used but should be explicitly identified as in EulerAngle3i3, for example. 

The standard allows use of any of the standard set of units (degrees or radians in this case). 


Table 4 — Standard variable name table excerpt 


Symbol 

Short 

Name 

Full Variable Name 

_ . Positive Sign Min Max 

escrip ion Convention Value Value 

Vehicle Positions and Angles 

£ 

EUL(3) 

eulerAngle_deg ( 3 ) 
eu 1 e r Ang 1 e_r ad ( 3 ) 

Array of the ownship roll, pitch, and yaw Euler angles comprised 
of the elements defined below LL (locally level) coordinate 
system, 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Min 

Value 

Max 

Value 


PHI 

eul erAng 1 e_deg_Rol 1 
eul erAng 1 e_r adJRol 1 

Roll Euler Angle, LL 
coordinate system 

RWD 

-180, -ii 

180, 7i 

e 

THET 

eulerAngle_deg_Pitch 
eul erAng 1 e_r ad_Pi tch 

Pitch Euler Angle, LL 
coordinate system 

ANU 

-90, -ti/2 

90, ti/2 


PSI 

eulerAngle_deg_Yaw 
eule r Ang le_r ad_ Y aw 

Yaw Euler Angle, LL 
coordinate system 

ANR 

- 180 ,-ti 

180, 7i 


6.7 Summary 

While it is recommended that this naming convention be adopted for defining future variables, the real key 
to a standard variable name is not the name, but the definition of the name. To exchange information 
between two or more organizations, the most important factor is not whether a variable is named 
“airspeed" or “vrw," but that there exists a precise, unambiguous definition of the variable (true, 
indicated, or calibrated airspeed, etc ), including units and coordinate system 

Using the standard variable name simply provides a common language and set of definitions within which 
to facilitate transfer of the model 

The simulation community is encouraged to propose additional standard variable names Annex C 
describes the web site used to support this standard There is an appropriate URL or email address for 
submitting additional names or for recommending clarification of existing names 
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7 Standard Simulation Data Format and XML Implementation of the 
Standard: DAVE-ML 

7.1 Purpose 

This section explains the requirements that a standard simulation data format must be able to satisfy It 
includes the content of defined functions and configuration management of the content The definition of 
the DAVE-ML format includes data for these components. 

This document also discusses conceptually how a data table should be accessed in an executable 
program 

The standard is implemented in XML as specified by DAVE-ML Annex B is the current version of the 
DAVE-ML reference document Annex C provides links to example programs for loading and looking up 
data conforming to the XML standard 

7.2 Philosophy 

Probably the greatest benefit of the standard to the simulation discipline is the definition of formats for the 
interchange of tabular data. Tabular data is used widely for non-linear function representation of 
aerodynamic, engine, atmospheric, and many other model parameters. The simplified interchange of 
such data should improve efficiency in the simulation community. 

Most simulation developers and users have addressed this issue locally. In many simulation communities, 
a family of tools has been built around existing local function table formats The intent of this standard is 
not to replace these local standards, but rather to define a format for communication that will allow each 
site to develop a single format converter to and from their local format The DAVE-ML data representation 
is proposed as an exchange standard. 

7.3 Design Objective 

The first design objective of the standard data table format was to include all relevant information about 
real multi-dimensional functions, not just the data values. In the general case of a multi-dimensional table, 
the independent variables have different numbers of breakpoints, different breakpoints, and different valid 
ranges, which are all relevant to consistent evaluation of the function 

An equally important design objective was to allow the table to contain information on the data source 
(provenance, via reference), and a confidence interval for the data Uses of confidence intervals within a 
model include direct computation of output confidence levels, estimation of output confidence intervals 
through Monte Carlo simulations, and mathematically combining different estimates of the same 
parameter at the same input values. Therefore, confidence statistics should be included when updating 
an existing or creating a new data set. DAVE-ML allows different types of confidence intervals, not all of 
which can be meaningfully combined 

The data format must also be easily read by computer or human, and be as self-documenting as 
possible 

7.4 Standard Function Table Data — An Illustrative Example 

Figure 4 presents a fairly standard three-dimensional set of aerodynamic data typical of flight test or wind 
tunnel results. In the example, lift coefficient is a function of angle-of-attack, Mach number, and a control 
surface position. More generally stated, the function output (dependent variable) CLALFA is dependent 
on three inputs (independent variables): angleOf Attack_deg. mach, & 
con t rol Sur f a cePos_deg_avgEl e va tor 

The example illustrates the following characteristics 
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1) The number of breakpoints may be different for each independent variable Data is presented for 

a different number of angle-of-attack (angieofAttack_deg) points at each combination of 
Mach number (mach) and control position (controlSurfacePos_deg_avgElevator). For the 
first combination of Mach number and control position (mach = 0.6, 

control surf acePos_deg_avgEi evator = 5) there are 17 angle-of-attack points. For the last 
combination of Mach number and control position (mach = 0.8, 

control surf acePos_deg_avgEi evator = 0) there are 12 angle-of-attack points There are 
also different numbers of Mach number points for each control position The standard requires 
this to be represented as an ungridded table 

In contrast, a gridded table would require an function value be defined for every combination of a 
fixed set of Mach, angle-of-attack and control position breakpoint values. 

2) At some breakpoints, the values of the other independent variables are different. Again, this is a 
characteristic of an ungridded table. 

3) The valid ranges of the independent variables are different, another ungridded table 
characteristic. 

4) The above three differences are not consistent for all data For example, in the sample table the 

angleOf Attack_deg, breakpoints for mach = 0.6 and mach = 0.7 and for 

controlSurfacePos_deg_avgElevator = -5 are identical. 
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Figure 4 — An illustration of a three-dimensional function table 

For function data there is other information that is of importance to the user, without which the data is not 
very useful. In general this information is as follows, 

a) Where did the data come from? For example what wind tunnel test or computational model? 

b) How is it defined? For example, is this at a specific altitude? What is the vehicle configuration ? 

c) What are the engineering units of the output (the dependent variable) and the independent variables? 

d) What is the sign convention of the independent and dependent variables? For example, is the control 
position positive trailing edge up or trailing edge down? Exactly which control surface is it? 

e) Who created the table? Not where the data came from, but what person decided that this was the 
correct data for this table? 

f) How has it been modified and for what reason? 

g) How accurate is the data estimated to be? Or, mathematically what is the confidence interval of the 
data? 

h) By what method is the data intended to be interpolated? For example, linear interpolation or cubic 
spline interpolation? 

i) By what method is the data intended to be extrapolated when the independent variable values are 
outside the specified range for the breakpoint data? 

The DAVE-ML grammar has data elements that contain all of the above information. It also includes the 
ability to automate static checks of the function data to allow spot checking of the function after it has 
been exchanged It is discussed in detail in the DAVE-ML reference document contained in Annex B, An 
introduction and overview of DAVE-ML’s seven major elements is provided here 

7.5 DAVE-ML Major Elements (Annex B) 

The major elements of DAVE-ML are listed below in the order required by the DAVE-ML DTD The root 
element of a DAVE-ML model file, DAVEfunc, can have several sub-elements and attributes; most 
attributes and sub-elements are optional. The only sub-elements a DAVE-ML file must contain are the 
fileHeader and at least one variableDef 

Information (breakpoints, data points, provenance, etc.) that is used by more than one major element 
should be defined once and then referenced in any subsequent use 

The sub-elements must appear in the following order (as required by the DTD): 

fileHeader — states the source and purpose of the file It must include the author's contact details 
and the file creation date, and may include a description, reference information, and modification 
history 

variableDef — each variableDef defines one of the constants or signals (variables) used in the DAVE- 
ML model, whether input, output or internal. The definition includes all the attributes and sub- 
elements required to fully characterize the variable of interest, including a MathML definition if the 
variable's value is equation-based. Standard variables as defined in Section 6 and Annex A are 
encouraged here. 

breakpointDef — defines breakpoint sets to be used in the model The breakpoints are the coordinate 
values along one axis of a gridded linear function value table One breakpointDef may be reused by 
several functions 

griddedTableDef — defines an orthogonally-gridded multi-dimensional table of the values of a 
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function at the intersection of a set of specified independent inputs (breakpoints). The coordinates 
along each dimension are defined in separate breakpointDef elements. 

ungriddedTableDef — defines a table of non-orthogonal values of a function, each with the values of 
their independent coordinates 

function — defines a function by connecting independent variables, breakpoints and data tables to 
their output value. 

checkData — contains one or more input/output vector pairs (and optionally a vector of internal 
values) for the encoded model to assist in verification and debugging of the implementation. 

Annex B contains the latest version of the DAVE-ML reference document, including a detailed description 
and examples of the data element definitions of the DAVE-ML standard Section 8 of Annex B provides 
detailed XML element references and descriptions. 

7.6 Simple DAVE-ML Examples 

The easiest way to understand the standard is through an example Annex B contains many more 
examples of the DAVE-ML implementation of the standard. 

A simple one dimensional relationship example, giving pitching moment coefficient as a function of angle 
of attack, is shown in Table 5 and Figure 5 


Table 5 — A simple one-dimensional function table 


anqleOf Attack deq 

0 

18 

19 

20 

22 

23 

25 

27 

90 

cm (anqleOf Attack deq) 

0.1 

-0.1 

-0.09 

-0 08 

-005 

-0 05 

-0 07 

-0.15 

-0 6 


cm (angleOfAttack_d) 



— cm(angleOfAttack_d) 


Figure 5 — A simple one-dimensional gridded function 
A DAVE-ML implementation for this function could be as follows. 

<?xml version="l. 0" encoding="UTF-8" standalone="no”?> 

< IDOCTYPE DAVEfunc PUBLIC " -//AIAA//DTD for Flight Dynamic Models - Functions 
2.0/ /EN" ’’DAVEfunc. dtd"> 

<DAVEf unc xmlns= "http : / /daveml . org/2010/DAVEML"> 

< 1 - File Header Components =============== 
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< ! — ========================== — > 

<f ileHeader> 

<!-- This is an example of the file header components of the 

derivative of Cm as a function of angle of attack. It must 
define all documents that are later referenced by any function. 

Note that there is not much information in this header, 
because it is meant to be a simple example. In 
reality, probably the most important information is the 
author, the reference and the modification record, because 
these data describe where the data came from and if it has 
been changed (and how) . See annex B for more complete 
examples . 


<author name="Bruce Hildreth” org="JFTI" email=”bhildreth@jf ti . com”/> 

<f ileCreationDate date* ”2006- 03- 18" /> 

<description> 

This is made up data to use as an example of a simple gridded function. 
</description> 

<reference ref ID=”BLHRptl" author*" Joe Smith" 

title="A Generic Aircraft Simulation Model (does not really exist) " 
accession* "ISBN 1-2345-678-9" date="2004 -01-01"/> 

<!-- no modifications so far, so we don't need a modif icationRecord yet --> 

</f ileHeader> 

< ! — ================================== — > 

< ! --============= Variable Definition Components == === === === ==== - - > 

< ! — =========== ====== ========= ====== = = — > 


<!-- Input variable --> 

cvariableDef name* "Angle of attack" varID="angleOf Attack" units="deg" > 
<isStdAIAA/> <!-- Indicates that this variable is a standard 
variable, which is why the author omitted 
description and sign convention 
and any other info, (it certainly could 
be included here) --> 

</variableDef > 

<!-- Output (function value) --> 

cvariableDef name* "Pitching moment coefficient due to angle of attack" 
varID="CmAlfa" units* "nondimensional" sign="+ ANU"> 
cdescription> 

The derivative of total pitching moment with respect to 
angle of attack. 

</description> 

</variableDef > 

< ! — ========== =================== - - > 

<!--============= Breakpoint Definition Set =============== - - > 

cbreakpointDef bpID="angleOf Attack_bpl" > 

< ! - - 
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Note that the bpID can be any valid XML string to uniquely identify 
the breakpoints. The author here chose to use a name related to the 
independent variable that is expected to be used to look up the function. 
In fact, if this set of breakpoints were shared by many functions 
and different independent variables would be used to look up the 
function, then the bpID of "angleOf Attack__bpl" would be 
misleading and a more generic name like "AOA" would probably be 
better. 

- -> 

<description> 

Angle of attack breakpoint set for CmAlfa, CdAlfa, and ClAlfa 
< /descript ion> 

<bpVals> <!-- Always comma separated values --> 

0, 18, 19, 20, 22, 23, 25, 27, 90 
</bpVals> 

</breakpointDef > 

< ! - -*======■*==**= Gridded Table Definition 

<gr iddedTabl eDef gtID="CmAlfa_Tablel"> 

<description> 

The derivative of Cm wrt fuselage AOA in degrees 
< /descript ion> 

< provenance > 

<author name="Jake Smith” org= " A1 Corp " / > 

<functionCreationDate date= "2006-12-31” /> 

<documentRef ref ID= "ELHRptl" /> <1-- This points back to the Header, 
which provides the information 
about BLHRptl. --> 

< /provenance> 

<breakpointRef s> 

<bpRef bpID="angleOf Attack_bpl" /> 

</breakpointRefs> 

cuncertainty effect* "percentage" > 
cnormalPDF numSigmas* " 3 ” > 

<bounds>12< /bounds > 

</normalPDF> 

<1-- This means that the 3 sigma confidence is +-12% on the Data. --> 

< / uncertainty > 

<-dataTable> <!-- Always comma separated values --> 

0.1, -0.1, -0.09, -.08, -0.05, -0.05, -0.07, -0.15, -0.6 
</dataTable> 

</griddedTableDef > 

<!-- ===■=================: 

< ! - -============= Function Definition 




<!-- The function definition ties input and output variables 

with table definitions. This allows a level of abstraction such 
that the table, with its breakpoint definitions, can be reused 
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by several functions (such as left and right aileron or multiple 
thruster effect tables) . 


< f unc t ion na me = M Cm_a 1 pha_f unc ” > 

<description> 

Variation of pitching moment coefficient with angle of attack (example) 
< /descript ion> 

<independentVarRef varID= "angleOf Attack" /> 

<dependentVarRef varID= "CmAlf a" / > 

<f unctionDefn> 

<griddedTableRef gtID= "CmAlf a_Tablel" /> 

</functionDef n> 

</ f unction> 

< 1 - - = =============== ===== --> 

<!--============= Check Data Cases =============== --> 

<!-- Checkcase data provides automatic verification of the model by 
specifying the tolerance in output values for a given set of 
input values. One ' staticShot' is required per input/output 
mapping; in this case for a single input, single output model, 
we have a single input signal and a single output signal in each 
test point . 


<checkData> 

<staticShot name="case 1”> 
<checklnputs> 

<signal> 

<varID>angleOf Attack</varID> 
<signalValue> 0 . </signalValue> 

</ signal > 

</checkInputs> 

< checkout put s > 

<signal> 

<varID>CmAlf a</varID> 
<signalValue>0 . 01</signalValue> 
<tol>0 . 00001c/ tol> 

</signal> 

< /checkOutputs> 

</staticShot> 

<staticShot name* "case 2”> 
<checklnputs> 

<signal> 

<varID>angleOf Attack</varID> 
<signalValue> 5 . </signalValue> 
</signal > 

< /checklnputs> 

< checkOutput s > 

<signal> 

<varID>CmAlf a</varID> 
<signalValue>0 . 04444</signalValue> 
<tol>0 . 00001</tol> 

</signal> 

< /checkOutputs> 

</staticShot> 

<staticShot name="case 3”> 
<checklnputs> 

<signal> 

<varID>angleOf Attack < /varID> 
<signalValue>10 . </signalValue> 
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</signal> 

< / check I nput s > 

<checkOutputs> 

<signal> 

<varID>CmAlf a< /varID> 
<signalValue>-0 . 01111</signal Values 
<tol>0 . 00001</tol> 

</signal> 

</checkOutputs> 

</staticShot> 

<staticShot name="case 4”> 
<checklnputs> 

<signal> 

cvarlDsangleOf Attack< /varID> 
<signalValue>15 ,</signalValue> 
</signal> 

</checkInputs> 

< che ckOut put s > 

<signal> 

<varID>CmAlfa</varID> 
<signalValue>-0 . 06667</signalValue> 
<tol>0 . 00001</tol> 

</signal> 

< /checkOutputs> 

</staticShot> 

<staticShot name=”case 5"> 
<checklnputs> 

<signal> 

<varID>angleOf Attack</varID> 
<signalValue>20 . </signalValue> 
</signal> 

</checkInputs> 

< che ckOutput s > 

<signal> 

<varID>CmAlf a</varIDs 
<signalValue>-0 . 08</signalValue> 
<tol>0 . 00001</tol> 

</signal> 

</checkOutputs> 

< / sta t i cShot » 

<staticShot name="case 6"> 
<checklnputs> 

<signal> 

<varID>angleOf Attack</varID> 
<signalValue>25 . </signalValue> 

< /signals 
</checkInputs> 
t checkout put s> 

<signal> 

<varID>CmAlf a< /var ID> 
<signalValue>-0 . 07</signalValue> 
<tol>0 . 00001</tol> 

</ signals 
</checkOutputs» 

</staticShots 

cstaticShot name=”case 1 "> 
<checklnputs> 

<signal> 

<varID>angleOf Attack< /varID> 
<signalValue>50 . </signalValue> 
</signal> 

</checkInputs> 

<checkOutputs> 

<signal> 
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<varID>CmAlf a< /varID> 

<signalValue>-0 . 31429</signal Values 
<tol>0 . 00001</tol> 

</signal> 

< / checkout put s> 

</staticShot> 

< / checkDa ta > 

</DAVEf unc> 

While the above seems excessively long for a function with only 9 data points, most of its content involves 
self-documentation and checking Therefore, as well as the function's data it includes the data's units, 
coordinate systems, uncertainty descriptions and provenance. It also includes many instructional 
comments, and verification data for multiple simulation conditions. Also, a very large complex function 
would only be expanded by the additional data points The definitions and provenance information 
included with the function would probably not change much. 

In the minimum, the same nominal data can be represented as shown. It is also possible to completely 
remove all whitespace between elements for more compactness, but this greatly affects readability by 
humans. 

<?xml versions” 1 . 0" encoding- " UTF 8 " standalone* "no" ?> 

<!DOCTYPE DAVEfunc PUBLIC ” -//AIAA//DTD for Flight Dynamic Models - Functions 
2.0//EN” " DAVEf unc . dtd " > 

< DAVEfunc xmlns= "http : / /daveml . org/2010/DAVEML" > 

<f ileHeader> 

<author name="Bruce Hildreth" org="SAIC"/> 

<f ileCreationDate date= "2006- 03 - 18" /> 

</f ileHeader> 

<variableDef name="Angle of attack” varID="angleOfAttack" 
units= "deg"/> 

cvariableDef names " CMalpha" varlDs "CmAlf a" un ltss ” " / > 
cbreakpointDef bpIDs”angleOf Attack_bpl” > 

cbpVals> 0, 18, 19, 20, 22, 23, 25, 27, 90 c/bpVals> 

< /breakpointDef > 

<griddedTableDef gtID="CmAlfa_Tablel"> 

<breakpointRef s> 

cbpRef bpID=”angleOf Attack_bpl"/> 

</breakpointRef s> 

<dataTable> 0 . 1, -0 . 1 , -0 . 09 , -.08, -0.05, -0.05, -0.07, -0.15, -0.6 
< /dataTable> 

< /gr iddedTableDef > 

<f unction name="Cm_alpha_func"> 

cindependentVarRef varID="angleOf Attack" /> 

<dependentVarRef varID= "CmAlf a" / > 

<functionDefn> 

<gr iddedTabl eRef gtID=" CmAl f a_Table 1 " / > 

</functionDefn> 

</function> 

</DAVEfunc> 


The other principal means of model representation in DAVE-ML is through Math-ML elements, which are 
used to specify calculations 

For example: 

totalThrust_N= engine1Thrust_N + engine2Thrust_N + engine3Thrust_N 

This equation, which is part of the model being exchanged, may be encoded in DAVE-ML and exchanged 
as data as shown below 

<?xml versions" 1 . 0" encoding="UTF-8" standalone* "no" ?> 
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< 1DOCTYPE DAVEfunc PUBLIC " -//AIAA//DTD for Flight Dynamic Models - Functions 
2.0//EN” "DAVEfunc. dtd"> 

<DAVEfunc xmlns= "http : //daveml . org/2010/DAVEML" > 

<f ileHeader> 

<author name=”Dan Newman" org="Quantitative Aeronautics " /> 

<creationDate da te=" 2009-11-10 "/> 

<description> 

Simple MathML example : total thrust is the sum of three inputs. 

< /descriptions 
</f ileHeader> 

<variableDef name="Engine #1 thrust" varID="enginelThru.st" units="N”/> 
<variableDef name="Engine #2 thrust" varID="engine2Thrust" units="N"/> 
<variableDef name=”Engine #3 thrust” varID="engine3Thrust” units=”N"/> 
<variableDef name=”Total thrust" varID="totalThrust" units=”N" > 

<calculation> 

<math> 

<apply> 

<plus/> 

<ci>enginelThrust</ci> 

<ci>engine2Thrust</ci> 

<ci>engine3Thrust</ci> 

</apply> 

</math> 

< /calculations 
</isOutput> 

</variableDef > 

</DAVEf unc> 

7.7 Summary 

The DAVE-ML implementation of the standard enables nearly effortless transfer of simulation 
aerodynamics models between simulation facilities or architectures. Inclusion of Math-ML elements allows 
the formulation of algebraic equations, such as aerodynamic, propulsion, inertial, landing gear or control 
system models, to be included as data in the model DAVE-ML is also suitable for use or transfer of 
tabular functions and algebraic equations for any type of data, not just simulation models 

While the above paragraphs provide an overview of the concepts implemented in DAVE-ML, Annex B is 
the normative authority for this standard. It includes much more detail and examples on how to easily 
build a DAVE-ML compliant simulation. Annex C provides a reference to the DAVE-ML web site, which 
includes tools that facilitate use of DAVE-ML based models in many applications. 
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8 Future Work 

The AIAA Modeling and Simulation Technical Committee plans to continue its efforts in facilitation of the 
exchange of simulations and models throughout the user community Comments and suggestions on this 
expansion are welcomed on the simulation standards discussion group Visit http://www.daveml.org for 
submittal information. The following sections describe the two tasks of primary interest. 

8.1 Time History Information 

The immediate task that is being pursued is the transfer of validation data between facilities This is for 
the purpose of sending time response validation data when a model is exchanged 

The approach being taken is to adopt a flight test data standard. This has the advantage of using an 
existing standard and facilitating the use of flight test data to validate a simulation. Lockheed Martin has 
an existing internal standard that they have released for use by the community. It is implemented in 
hierarchal data format (HDF) and has been adopted by the JSF community and other programs It is the 
Modeling and Simulation Technical Committee’s intent to adopt this for the transfer of simulation 
validation data Some work will be required to define the data elements that are required for the validation 
of a simulation. This is expected to be a subset of the data elements that comprise flight test data 

8.2 Dynamic Element Specification 

The addition of the specification of dynamics (e g continuous and discrete states) is being considered to 
expand the scope of the standard. This expansion would allow more of the domain of a flight vehicle 
model (flight controls as a good example) to be exchanged in a non-proprietary, facility-neutral way. 
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9 Conclusion 

This is a standard for the purpose of facilitating the exchange of simulation models between users. This 
purpose cannot be emphasized enough. It is not meant to enforce any standard simulation architecture 
DAVE-ML provides the mechanism for exchange of the modeling data and equations, the standard 
variables and coordinate systems provide a common language to facilitate effective communication. The 
standard is also valuable for documenting a model, since the names and coordinate system definitions 
are clearly documented for the user 

A model can be DAVE-ML compliant without using any standard names or coordinate systems, but the 
exchange of such a model between users will be more difficult, since clear definitions will have to be 
exchanged also 

It is the earnest desire of the authors of this standard that the user community will employ the current 
standard for aerodynamic models, continue to suggest improvements to the standard, and develop tools 
to enhance the standard, http: //www.daveml .org contains information on how to be part of this effort 
and/or submit change or improvement recommendations. 


58 


NESC Request No.: 09-00598 


© 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

128 of 
343 


10 Standard Variable Names (Normative) 

(Now a separate .doc for ease of editing) 
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Standard Variable Names (Normative) 

A.1 General 

The standard variable naming convention is described in detail in Section 6. The table in this annex 
contains a set of standard simulation variables that are independent of the particular vehicle type being 
simulated Use of these standard variables provides a "standard language" which will facilitate the 
communication of the information required to exchange simulation models. These variables are tailored 
towards aircraft simulation and to a lesser extent, spacecraft. Visit http: / /EaveML • om to suggest 
additional variables or changes to the existing list. 

A.2 Table Explanation 

Interpretation of the standard variable name table is best given by example In general the table has 7 
columns. These are described below using the eulerAngle_Roll as an example: 

1) The symbol for that variable, <I> 

2) The short name, PHI 

3) One or more full names using the standard units conventions — generally, one full name with 
American convention units and one with SI units. Refer to section 6 for a list of the standard units 
and their abbreviations 

NOTE While the variable naming convention described in Section 6 encourages the use of the 
<variable domain> component, this Annex does not include variable domains as part of the normative 
standard names. This is because the variable domain is normally dependent upon the simulation 
architecture, and as such is immaterial to the exchange of a simulation model unless the exchange is 
between facilities with similar architectures. 

NOTE: Any suitable units may be used. In the example for eulerAngle_Roll both the _deg for 
degrees and the _rad for radians are given. The "Full Variable Name" column does not necessarily 
provide all acceptable units for each variable 

4) A description of the variable, if applicable should always specify the coordinate system. Refer to 
section 5 for a description of the standard coordinate systems. 

5) The POSITIVE sign convention of the variable — RWD indicates that positive 
eul e r Angi e_Roi l is right wing down (See section A. 2.1 fora list of sign convention acronyms) 

6) Minimum value, normally only specified for angles 

7) Maximum values of the variable, normally only specified for angles 
Note: 

This example also illustrates the pitch and yaw Euler angles. 

Some variables may be used to represent variables referenced to more than one coordinate system. In 
this case the coordinate system is specified as xx and any coordinate system reference (refer to the body 
of this standard) may be substituted for the xx. For example, xxVeiocity_f t_s_Y may represent: 

eiVeiocity_ft_s_Y for the velocity along the Y axis of the ei coordinate system - Earth centered 
Inertial (also known as geocentric inertial) coordinate system 

geVelocity_ft_s_Y for the velocity along the Y axis of the geocentric Earth (ge) coordinate system. 
Also referred to as the Earth Centered Earth Fixed (ECEF coordinate system). 
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voVeioc ity_f t_s_Y for the vo coordinate system (Vehicle carried, Orbit defined coordinate system) 

Roll, pitch and yaw may also conveniently be expressed as an array Again, eulerAngle_rad [3] ‘ 
would be the standard array using radians as the units and is fully compliant with the standard. 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive 

Sign 

Convention 

Min 

Value 

Max 

Value 

£ 

EUl[3] 

eulerAngle_deg [3] 
eulerAngle_rad [3] 

Array of the roll, pitch, and yaw Euler angles comprised of the 
elements defined below LL (locally level) coordinate system 

<P 

PHI 

eulerAngle_deg_Roll 
eu 1 e r Ang 1 e_r ad_Ro 1 1 

Roll Euler Angle, LL 
coordinate system 

RWD 

-180, -a 

180, a 

9 

THET 

eulerAngle_deg_Pitch 

eulerAngle_rad_Pitch 

Pitch Euler Angle, LL 
coordinate system 

ANU 

-90, -ji/2 

90, a/2 


PSI 

eu 1 e r Ang 1 e_deg_ Yaw 
Eu 1 er Ang 1 e_r ad_Y aw 

Yaw Euler Angle, LL 
coordinate system 

ANR 

-180, -a 

180, a 


The variable name table below does not specify which variables are states, state derivatives, inputs, 
disturbances, simulation controls or initial conditions These specifications may be added to any 
appropriate variable Refer to Section 4 2 in the body of this standard for use of dynamic equation 
prefixes and section 6.4,8 for initial condition specification. 


1 A number or pair of numbers between square brackets represents the number of elements in an array or matrix 
respectively. 
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S-119 


A. 2.1 Annex A Acronyms 
Positive Sign Convention Acrpnyms 

The following acronyms may appear as values for the "positive sign convention” of variables defined in 
the variable name tables. 

+X in the positive direction of the presentation coordinate system’s X-axis 

+Y in the positive direction of the presentation coordinate system’s Y-axis. 

+Z in the positive direction of the presentation coordinate system's Z-axis 

ABV positive above 

AFT positive aft 

AH positive above horizon 

ANR positive aircraft nose right 

ANU positive aircraft nose up 

BH positive below horizon 

BLO positive below 

CCFN positive counterclockwise from north 

COMP positive compressed 

CWFN positive clockwise from north 

DEC decrease 

DN or Down positive down 

E or East positive East 

FWD positive forward 

INC positive increase 

LED positive leading edge down 

LT or Left positive left 

MAC percent mean aerodynamic chord 

N or North positive North 

NSC no sign convention (variable is always positive) 

OUT positive outward 

POS always positive 

RT or Right positive right 

RTCL positive right of centerline 

RWD positive right wing down 
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TED positive trailing edge down 

TEL positive trailing edge left 

TER positive trailing edge right 

TEU positive trailing edge up 

UP positive up 

WOW weight on wheels 

Control Surface and Position Acronyms 
LEF leading edge flap 

TEF trailed edge flap 


Annex A Page 4 of 54 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

133 of 
343 


ANSI/AIAA S-119 Annex A. Standard Variable Names 


A. 3 Standard Variable Name Tables 

Table A 1 — Vehicle Positions and Angles 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 

e 

EUL 

eulerAngle_deg 13] 
eulerAngle_rad [3] 

Array of the roll, pitch, and yaw Euler angles defined below LL (locally level) 
coordinate system. 

0 

PHI 

eul e rAng 1 e_deg_Rol 1 
eul er Ang 1 e_rad_Rol 1 

Roll Euler Angle, LL coordinate 
system. 

RWD 


-180, 

-n 

180, 

71 

9 

THET 

eulerAngle_deg_Pitch 
eu 1 e rAng 1 e_r ad_P itch 

Pitch Euler Angle, LL coordinate 
system 

ANU 


-90, - 
n/2 

90, 

71/2 

V 

PSI 

eul er Ang 1 e_deg_Y aw 
eu 1 er Ang 1 e_rad_Yaw 

Yaw Euler Angle, LL coordinate 
system 

ANR 


-180, 

-71 

180.71 

sin O 

SPHI 

s i nEu 1 e rAng 1 e_Rol 1 

Sine Of Euler Roll Angle 

RWD 


-1.0 

1.0 

COS 0 

CPHI 

cosEulerAngle_Roll 

Cosine Of Euler Roll Angle 

RWD 


-1.0 

1.0 

sin 0 

STHT 

s i nEu 1 er Ang 1 e_Pi tch 

Sine Of Euler Pitch Angle 

ANU 


-1.0 

1.0 

COS0 

CTHT 

cos Eu 1 er Ang 1 e_Pi tch 

Cosine Of Euler Pitch Angle 

ANU 


0.0 

1.0 

sin qj 

SPSI 

sinEulerAngle_Yaw 

Sine Of Euler Yaw Angle 

ANR 


-1.0 

1.0 

cos qj 

CPSI 

co s Eu 1 e r Ang 1 e_ Yaw 

Cosine Of Euler Yaw Angle 

ANR 


-1.0 

1.0 

Tfe/b 

T 

f eToBodyT [3,3] 

The FE to Body transformation matrix composed of the elements defined below 

Tfe/bP ,1] 

Til 

f eToBodyTl 1 

CTHT*CPSI (FE To B) coordinate 
transformation element 





Tfe*[2,1] 

T21 

f eToBodyT2 1 

SPHI*STHT*CPSI - CPHPSPSI 
(FE To B) coordinate 
transformation element 
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Sym bol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 

Tfe/bP.I] 

T31 

f eToBodyT31 

CPHI*STHT*CPSI + SPHI*SPSI 
(FE to B) coordinate 
transformation element 





Tfbb[1,2] 

T12 

feToBodyT12 

CTHT*SPSI (FE to B) coordinate 
transformation element 





Tfe/b[2,2] 

T22 

f eToBodyT22 

SPH 1 *ST HT*SPSI + CPHI*CPSI 
(FE to B) coordinate 
transformation element 





Tfe/b[3,2] 

T32 

f eToBodyT32 

CPHI*STHT*SPSI - SPHPCPSI 
(FE to B) coordinate 
transformation element 





Tfe/b[1,3] 

T13 

f eToBodyTl 3 

-STHT (FE to B) coordinate 
transformation element 





T fe ®[2.3] 

T23 

f eToBodyT2 3 

SPHPCTHT (FE to B) coordinate 
transformation element 





Tfe/b[3,3] 

T33 

f eToBodyT33 

CPHPCTHT (FE to B) coordinate 
transformation element 





Y 

GAMV 

f lightPathAngle_rad 

Flight Path Angle Above Horizon 

ANU 


-h/2 

n/2 



f light PathAngle_deg 




-90 

90 

X 

GAMH 

f 1 ight PathAz imuth_rad 
flight Pa thAzimuth_deg 

Flight Path Angle In Horizon 
Plane, from North 

CWFN 


-71 

-180 

71 

180 

h 

ALT 

altitudeMsl_f t 
altitudeMsl_m 

Geometric altitude of vehicle 
altimeter above Mean Sea Level 

UP 
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Sym bol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 

X 

XLON 

geLong i tude_rad 
geLong i tude_deg 

Note The coordinate system may be deleted if Ge 
coordinate system, resulting in 

longitude_rad 
long i t ude_deg 

Longitude of Vehicle 
Cm with respect to the ge 
(geocentric Earth) coordinate 
system. 

WEST 




<P 

XLAT 

geLatitude_rad 
geLa t i tude_deg 

Note The coordinate system may be deleted if Ge 
coordinate system, resulting in 

latitude_rad 

latitude_deg 

Geodetic Latitude of Vehicle 
Cm with respect to the ge 
(geocentric Earth) coordinate 
system. 

NORTH 





XLONIM 

U 

geLongi tudeOf Imu_rad 
geLong i tudeOf I mu_deg 

Note The coordinate system may be deleted if Ge 
coordinate system, resulting in 

longi tudeOf Imu_rad 
1 ong i tudeOf I mu_deg 

Longitude of Vehicle 
Imu with respect to the ge 
coordinate system. This variable 
does not include any Imu sensor 
errors. 

West 





XLATIMU 

gelati tudeOf Imu_rad 
gelati tudeOf Imu_deg 

Note The coordinate system may be deleted if Ge 
coordinate system, resulting in 

1 at i tudeOf I mu_rad 
1 at i tudeOf I mu_deg 

Geodetic Latitude of Vehicle 
Imu with respect to the 
Gecoordinate system. This 
variable does not include any Imu 
sensor errors. 

NORTH 
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Sym bol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 



g eS en s edLong i tudeOf I mu_r ad 
eSensedLong i tudeOf Imu_deg 

Note The coordinate system may be deleted if Ge 
coordinate system, resulting in 

sensedLong i tudeOf Imu_rad 
sensedLongi tudeOf Imu_deg 

Longitude of Vehicle 
Imu with respect to the Ge 
coordinate system. This variable 
includes any Imu sensor errors. 

West 






geSensedLati tudeOf ImuWrtZzz_rad 
geSensedLati tudeOf ImuWrtZzz_deg 

Note The coordinate system may be deleted if Ge 
coordinate system, resulting in 

sensedLatitudeOf Imu_rad 
sensedLati tudeOf Imu_deg 

Geodetic Latitude of Vehicle 
Imu with respect to the Ge 
coordinate system This variable 
includes any Imu sensor errors. 

NORTH 





HGT RW 
Y 

runwayHeightWrtMsl_f t 
runwayHeightWrtMsl_m 

Height Of Runway w.r.t mean Sea 
Level 

Above 






General Definition 

xxPositionOfYyyWrtZzz_f t [3] 
xxPositionOf YyyWrtZzz_m [3] 

For Example: 

xxPosition_f t [3] 

is the same as 

xxPositionOf CmWrtxx_ft [3] 

General Definition for Linear and Anqular Positions Refer to section 6 of 
this standard for complete guidance on the naming of variables. 

Vector of positions of Yyy with respect to Zzz (a user defined reference point or 
coordinate system origin) in the xx coordinate system. The lengths of xx, Yyy, 
Zzz are not restricted to 2 and 3 characters respectively. 

The coordinate system xx must always be defined. If the OfYyy is not defined 
the definition defaults to the vehicle Cm for linear positions and the body 
coordinate system for angular positions. If the WrtZzz is not defined the 
reference point defaults to the origin of the xx coordinate system for linear 
position and the locally level (LI) coordinate system for angular position. 

Comprised of the three components as defined below 
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Sym bol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 



xxPositionOfYyyWrtZzz_f t_X 
xx Po s i t i onOf YyyWr t Z z z _m_X 

or 

xxPosition_f t_X 

X position of Yyy with respect to 
Zzz (a user defined reference 
point) in the xx coordinate system. 

Defaults to the Cm and origin of 
the xx coordinate system. 

(Yyy -Zzz) 






xx Po s i t i onOf YyyWr t Z z z_f t_Y 
xxPositionOfYyyWrtZzz_m_Y 

or 

xxPosition_f t_Y 

Y position of Yyy with respect to 
Zzz (a user defined reference 
point) in the xx coordinate system 

Defaults to th Cm and origin of the 
xx coordinate system. 

(Yyy -Zzz) 






xxPos itionOf YyyWr tZzz_ft_Z 
xx Po s i t i onOf YyyWr t Z z z _m_Z 

or 

xx Po s i t i on_f t_Z 

Z position of Yyy with respect to 
Zzz (a user defined reference 
point) in the xx coordinate system 

Defaults to the CG and origin of 
the xx coordinate system. 

(Yyy -Zzz) 






f ePosition_f t [3] 

Vector of positions of the CM in the flat Earth coordinate system. 
Comprised of the three components as defined below. 


XCG 

f ePosition_f t_X 

X or North position of the CM in 
the flat Earth coordinate system 






YCG 

f ePos i t ion_f t_Y 

Y or East position of the CM in the 
flat Earth coordinate system 






ZCG 

f ePosition_f t_Z 

Z or Down position of the CM in 
the flat Earth coordinate system 

minus equals 
above the 
ground 
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Sym bol 

Short 

Name 

Full Variable Name 

Descnption 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 



xxPositionOfMrcWrtZzz_f t_X 
xxPo8itionO£MrcWrtZzz_m_X 

X position of the moment 
reference center (Mrc) with 
respect to Zzz in the xx 
coordinate system 







xxPo8ition0fMrcWrtZzz_f t_Y 
xxPositionOfMrcWrtZzz_m_Y 

Y position of the moment 
reference center (Mrc) with 
respect to Zzz in the xx 
coordinate system 







xxPos i t ionOf MrcWrtZzz_f t_Z 
xxPo8ition0fMrcWrtZzz_m_Z 

Z position of the moment reference 
center (Mrc) with respect to Zzz in 
the xx coordinate system. 






REF [3] 

bodyPosi.tionO£Mrc_f t [3] 

Vector of positions of the aerodynamic moment reference center in the body 
coordinate system Since the origin of the body coordinate system is the Cm, 
this vector is the positions of the Mrc with respect to the Cm 

Comprised of the three components as defined below 


XREF 

body Pos i t i onOf Mr c_f t_X 

X position of the Mrc in the body 
coordinate system 

Mrc in front of 
the origin (Cm) 





YREF 

body Pos i t i onOf Mr c_f t_Y 

Y position of the Mrc in the body 
coordinate system 

Mrc out the 
right wing with 
respect to the 
origin (Cm) 





ZREF 

body Pos i t i onOf Mr c_f t_Z 

Z position of the Mrc in the body 
coordinate system 

Mrc below the 
origin (Cm) 




PLT2CG[ 

31 

bodyPos it ionOf PilotByeWrtCm_£ 13) 
bodyPos it ionOf Pi lotEyeWrtCm_f t [3) 

Vector of positions of the pilot's eye with respect to the Cm in the body 
coordinate system Comprised of the three components as defined below 


XPLT2C 

G 

bodyPos itionOfPilotByeW r t Cm_£ t_X 
body Pos itionOfPilotByeWrt Cm_f t_X 

X position of pilot eye point w.r.t 
Cm, in the body coordinate system 

Eye FWD of 
Cm 





YPLT2C 

G 

bodyPos i t i onOf Pilot Ey eWr t Cm_f t_Y 
bodyPos i t i onOf Pilot Ey eWr t Cm_£ t_Y 

Y position of pilot eye point w.r.t 
Cm, in the body coordinate system 

Eye Right of 
the Cm 
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Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Intial 

Value 

Min 

Value 

Max 

Value 


ZPLT2C 

G 

body Po sitionOfPilotEyeWrt Cm_f t_Z 
bodyPositionOf PilotEyeWrtCm_f t_Z 

Z position of pilot eye point w.r.t 
Cm, in the body coordinate system 

Eye below Cm 




EXAMPLES 



runway22Position_f t [3] 

indicates position of the Cm (default) with respect to the 
origin of the Runway22 coordinate system (default), in the 
runway22 coordinate system. A more complete and clear 
name would be: 

runway2 2 Pos i t i onOf CmWr t Runway 2 2_f t [ 3 ] 

runway22PositionOf FwdLef tMainWheelWrtTd ft [3 
] 

indicates position of the forward left main wheel with 
respect to the touchdown point in the Runway 22 
coordinate system 

NOTE All coordinate systems are user defined 

Vector of positions of the vehicle Cm relative to the Runv^y 22 (a user defined 
coordinate system) touchdown reference point. Comprised of the three 
components as defined below. 


XCGTD 

runway2 2 Pos i t i onOf CmWr tTd_f t_X 
runway22Pos i t ionOf CmWr tTd_m_X 

Cm X-position w.r.t. runway 
touchdown point in the specified 
(Runway22) coordinate system. 

Cm Down the 
runway from 
the reference 
point 





YCGTD 

runway2 2 Pos i t ionOf CmWr tTd_f t_Y 
runway 2 2 Pos i t i onOf CmWr t Td_m_Y 

Cm Y- position w.r.t. runway 
touchdown point in the specified 
(Runway22) coordinate system. 

Cm to the right 
of the 

reference point 





ZCGTD 

runway2 2 Pos i t i onOf CmWr t Td_f t_Z 
runway2 2 Pos i t i onOf CmWr tTd_m_Z 

Cm Z-position w.r.t runv^y 
touchdown point in the specified 
(Runway22) coordinate system. 
(This variable is normally 
negative ) 

Cm below the 
TD point 





RE 

smoothEarthRadius_f t 
smoothEarthRadius_m 

Geocentric radius of Earth (center 
to smooth surface), round Earth 
model or oblate spheroid at the 
nadir of the aircraft. 






Annex A Page 11 of 54 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

140 of 
343 


ANSI/AIAA S-119 


Annex A. Standard Variable Names 


Sym bol 
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Full Variable Name 
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Positive Sign 
Convention 

Intial 

Value 

Min 

Value 
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Value 


RALT 

heightOfCmWrtTerrain_f t 
heightOf CmWrtTerrain_m 
or 

heightWrtTerrain_f t 
heightWrtTerrain_m 

Height of the aircraft Cm above the 
terrain 

NSC 





HTERRAI 

N 

heightOf TerrainWrtGround_f t 
heightOf TerrainWrtGround_m 

Height of the terrain at the nadir of 
the aircraft Cm. It is the terrain 
height above the smooth surface 
of the Earth, regardless of whether 
a flat, round or oblate spheroid 
model is used. 






Table A 2 — Vehicle velocities and angular rates 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


VTxx 

total SpeedWrtXx_ft_s 
total SpeedWrtXx_m_s 

T otal Velocity with respect to and 
observed from Xx where Xx is the 
coordinate system as defined in 
the body of this standard. 

NSC 




Vk 

VG 

groundSpeed_f t_s 
g round Speed_m_s 

Vehicle speed along the ground . 

NSC 




Mn 

XMACH 

mach 

Mach number of the aircraft 

NSC 





ALTDxx 

xxAltitudeRate_f t_s 
xxAltitudeRate_m_s 

default coordinate system is locally level and -Z axis 

Altitude time rate of change in xx 
coordinate system. 

DN 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


XLOND 

xxLong i tudeRat e_rad_s 
xxLongitudeRate_deg_s 

Default is Ge coordinate system 

Longitude Rate Of Change in xx 
coordinate system. 

WEST 





XLATD 

xxlatitudeRate_rad_s 
xxl at i tudeRat e_deg_s 

Default is Ge coordinate system 

Geodetic Latitude Rate Of 
Change in xx coordinate system. 

NORTH 




General Definition-Translational Velocities 

xxVelocityOfYyyWrtZzzObsFrWww_f t_s [3] 
xxVelocityOf YyyWrtZzzObsFrWww_m_s [3] 

General Definition for Translational Motion: Refer to section 6 of this 
standard for complete guidance on the naming of variables. 

General expression for vector of velocities presented (or measured) in the xx 
coordinate system. Yyy indicates the reference point on the vehicle and the 
OfYyy may be omitted if it is the Cm. Z zz represents the coordinate system that 
the vehicle is moving with respect to and WrtZzz may be omitted if it is the xx 
coordinate system. ObsFrWww represents the coordinate system from which the 
vehicle motion is observed The ObsFrWww may be omitted if it is the Z zz 
coordinate system (see section 6.3.3 for more detail) 

Therefore eiVelocity_f t_s_X is the velocity of the vehicle Cm along the X 
axis of the ei coordinate system, measured with respect to the ei coordinate 
system and observed from the ei coordinate system and is the default 
expression for eiVelocityOfCmWrtEiObsFrEi_f t_s_X. 

General Definition-Angular Velocities 

xxAnggul arRateOf YyyWrt Zz z_r ad_8_ [ 3 ] 
xxAnggularRateOfYyyWrtZzz_deg_s_[3] 

General Definition for Rotational Motion: Refer to section 6 of this standard 
for complete guidance on the naming of variables. 

General expression for angular velocities presented in the xx coordinate system. 
Yyy indicates the reference coordinate system on the vehicle and the OfYyy 
may be omitted if it is the body coordinate system. Zzz represents the 
coordinate system that the vehicle is moving with respect to and from which the 
vehicle motion is observed The WrtZzz may be omitted if it is the locally 
level (LI ) coordinate system, (see section 6.3.3 for more detail) 

Therefore eiAngularRate_rad_s_Rol 1 is the angular rate of the body axis 
of the vehicle with respect to the locally level coordinate system and presented 
(or measured) in the Earth centered inertial (ei) coordinate system and is the 
default expression for eiAngularRateOfBodyWrtLl_rad_s_Roll 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

a 

<5M 

bodyAnqularRate rad s[3] 
bodyAngularRatedegs [3] 

Vector of body coordinate angular rates of the ownship body coordinate system 
with respect to the locally level (LI) coordinate system. 




Comprised of the three components as defined below Angular motion is always 
with respect to the LI coordinate system unless otherwise specified 

a 

a 

bodyAnqularRate deq s Roll 

Vehicle roll velocity, body 
coordinate system 

RWD 




a 

a 

bodyAngularRate deg s Pitch 

Vehicle pitch velocity, body 
coordinate system 

n 




i 

a 

bodyAnqularRate rad s Yaw 
bodyAngularRate_deg_s_Yaw 

Vehicle yaw velocity, body 
coordinate system 

ANR 




Ob 

OMB 

bodyAngularRateWrtEi_rad_s [3] 
bodyAngularRateWrtEi_deg_s [3] 

Vector of body coordinate angular rates with respect to the Earth centered 
inertial (Ei) coordinate system 

Comprised of the three components as defined below 

Pb 

PB 

bodyAngularRateWrtEi_rad_s_Roll 

bodyAngularRateWrtEi_deg_s_Roll 

Vehicle roll velocity, body 
coordinate system 

RWD 




<7b 

QB 

bodyAng u 1 ar Ra t eWr t E i_r ad_s_Pi t ch 
bodyAngularRateWrtEi_deg_s_Pitch 

Vehicle pitch velocity, body 
coordinate system 

ANU 




r B 

RB 

bodyAngularRateWrtEi_rad_s_Yaw 

bodyAngularRateWrtEi_deg_s_Yaw 

Vehicle yaw velocity, body 
coordinate system 

ANR 




Pv» 

PS 

saAngularRateOfBodyWrtEi_rad_s_Roll 
saAng u 1 ar Ra t eOf BodyWr t E i_deg_8_Ro 1 1 

Body coordinate system Roll rate 
about the X axis in the sa 
coordinate system, also know as 
stability axis roll rate. 

RWD 




r V f 

RS 

saAngularRateOfBodyWrtEi _rad_s_yaw 
saAngularRateOfBodyWrtEi_deg_s_yaw 

Body coordinate system Yaw rate 
about the Z axis in the sa 
coordinate system, also known as 
the Stability Axis yaw rate 

ANR 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

£ 

EULD 

eulerAngleRate_deg_s [3] 
eulerAngleRate_rad_s 13] 

Array of the roll, pitch, and yaw Euler angle rates defined below. LL (locally 
level) coordinate system 

4 

PHID 

eulerAngleRate_rad_s_Roll 

Euler roll rate, LL coordinate 
system 

RWD 




0 

THETD 

eu 1 er Ang 1 eRat e_r ad_s_Pi t ch 

Euler pitch rate, LL coordinate 
system 

ANU 




V 

PSID 

eu 1 e r Ang 1 eR a t e_r ad_s_Y aw 

Euler yaw rate, LL coordinate 
system 

ANR 




V 

VEL [3] 

bodyVe loci tyWr t A i r_f t_s [ 3 ] 
bodyVe loci tyWrtAi r_m_s [3] 

can also be expressed as: 

bodyVe locityOf CmWrtAir_f t_s [3] 

Vector of body coordinate velocities of the Cm with respect to the instantaneous 
wind comprised of the three components as defined below. 

This is the conventional body coordinate system airspeed vector. 

u 

U 

bodyVe loci tyWrtAi r_ft_s_X 
bodyVe locityWrtAir_m_s_X 

X-velocity Body coordinate 
system. 

FWD 




V 

V 

bodyVe loci tyWrtAir_f t_s_Y 
bodyVe 1 oc i tyWrtAi r_m_s_Y 

Y-velocity Body coordinate system 

RT 




w 

W 

bodyVe loci tyWrtAi r_f t_s_Z 
bodyVe loc i tyWrtAi r_m_s_Z 

Z-velocity Body coordinate system 

DN 




y. 

VELB[3] 

bodyVelocityWrtEi_f t_s [3] 
bodyVeloci tyWrtEi_m_s 1 3 ] 
can also be expressed as: 
bodyVeloci tvOf CmWrtEi ft s [ 31 

Vector of body coordinate inertial velocities of the Cm comprised of the three 
components as defined below. 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

UB 

UB 

bodyVe loci tyWr t E i _f t_s_X 
bodyVe loci tyWr t E i_m_s_X 

X-velocity Body coordinate 
system. 

FWD 




Vb 

VB 

bodyVeloci tyWrtEi_ft_s_Y 
bodyVe loc i tyWrtE i_m_s_Y 

Y-velocity Body coordinate system 

RT 





WB 

bodyVe 1 oc i tyWr t E i _f t_s_Z 
body Ve 1 oc i t yWr t E i _m_ s_Z 

Z-velocity Body coordinate system 

DN 




Zr 

VELE[3] 

bodyVeloci tyWrtGe_ft_s [3] 
bodyVeloci tyWrtGe_m_s [3] 

can also be expressed as: 

bodyVe loc itvOf CmWrtGe ft s[3] 

Vector of body coordinate Cm velocities with respect to the geocentric Earth 
(Ge) coordinate system 

Comprised of the three components as defined below 

Ue 

UE 

bodyVeloci tyWrtGe_f t_s_X 
bodyVeloci tyWr tGe_m_s_X 

X-velocity Body coordinate 
system. 

FWD 




Ve 

VE 

bodyVeloci tyWrtGe_f t_s_Y 
bodyVe 1 oc i tyWrtGe_m_s_Y 

Y-velocity Body coordinate system 

RT 




We 

WE 

bodyVeloci tyWrtGe_f t_s_Z 
bodyVeloci tyWrtGe_m_s_Z 

Z-velocity Body coordinate system 

DN 




V n 

VELFE 

f eVelocity_f t_s C 3 ] 
f eVelocity_m_s [3] 

Vector of Flat Earth (FE) coordinate translational velocities of the Cm comprised 
of the three components as defined below. 

Vn 

VNFE 

f eVe 1 oc i ty_f t_s_X 
f eVe 1 oc i ty_m_s_X 

Northward Velocity Over Flat 
Earth (FE) coordinate system [flat, 
non-rotating Earth] 

NORTH 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Ve 

VEFE 

f eVeloci ty_f t_s_Y 
f eVe loc i ty_m_s_Y 

Eastward Velocity Over Flat Earth 
(FE) coordinate system [flat, non- 
rotating Earth] 

EAST 




Vd 

VDFE 

f eVe loc i ty_f t_s_Z 
f eVe loc i ty_m_s_Z 

Downward Velocity Toward Earth 
Ctr,.(FE) coordinate system [flat, 
non-rotating Earth] 

DN 






geVelocity_f t_s [3] 
geVelocity_m_s [3] 

Vector of Geocentric Earth (Ge) coordinate translational velocities of the Cm 
comprised of the three components as defined below 

Vx E 

VXGE 

g eVe loci ty_f t_s_X 
g eVe loc i ty_m_s_X 

X axis velocity over the Earth in 
the geocentric Earth (GE) 
coordinate system in ft/sec 

+X 




Vv E 

VYGE 

g eVe 1 oc i ty_f t_s_Y 
g eVe 1 oc i ty_m_s_Y 

Y axis velocity over the Earth in 
the geocentric Earth (GE) 
coordinate system in ft/sec 

+Y 





VZGE 

g eVe loc i ty_f t_s_Z 
g eVe loc i ty_m_s_Z 

Y axis velocity over the Earth in 
the geocentric Earth (GE) 
coordinate system in ft/sec 

+Z 




OTHER EXAMPLES 

Vx„. 

VXGE 

geVelocity_km_s_X 

X axis velocity of the vehicle Cm 
is the geocentric (ge) coordinate 
system in kilometers/sec 

+X 






runway2 2 Ve 1 oc i ty_f t_s_Z 

Z axis velocity of the Cm in the 
user defined 'Tunway22" 
coordinate system in ft/s 

DN 
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Table A3 — Vehicle linear and angular accelerations 


Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



General Definition-Translational Accelerations 

xxAccelOf YyyWrtZzzObsFrWww_f t_s2 [ 3 ] 
xxAccelOf YyyWrtZzzObsFrWww_m_s2 [31 

General Definition for Translational Motion Refer to section 6 of this 
standard for complete guidance on the naming of variables 
General expression for vector of accelerations presented (or measured) in the xx 
coordinate system. Yyy indicates the reference point on the vehicle and the 
OfYyy may be omitted if it is the Cm. Zzz represents the coordinate system that 
the vehicle is moving with respect to and WrtZzz may be omitted if it is the xx 
coordinate system. ObsFrWww represents the coordinate system from which the 
vehicle motion is observed The ObsFrWww may be omitted if it is the Zzz 
coordinate system (see section 6.3.3 for more detail) 

Therefore eiVelocity_f t_s2_X is the acceleration of the vehicle Cm along 
the X axis of the ei coordinate system, measured with respect to the ei 
coordinate system and observed from the ei coordinate system and is the default 
expression for eiVelocityOf CmWrtEiObsFrEi_f t_s2_X. 



General Definition-Angular Accelerations 

xxAnggularAccelOfYyyWrtZzz_rad_s2_ [3] 
xxAnggularAccelOfYyyWrtZzz_deg_s2_ [3] 

General Definition for Rotational Motion Refer to section 6 of this standard 
for complete guidance on the naming of variables. 

General expression for angular accelerations presented in the xx coordinate 
system. Yyy indicates the reference coordinate system on the vehicle and the 
OfYyy may be omitted if it is the body coordinate system. Zzz represents the 
coordinate system that the vehicle is moving with respect to and from which the 
vehicle motion is observed The WrtZzz may be omitted if it is the locally 
level (LI ) coordinate system, (see section 6.3.3 for more detail) 

Therefore eiAngularAccel_rad_s2_Roll is the angular acceleration of the 
body axis of the vehicle with respect to the locally level coordinate system and 
presented (or measured) in the Earth centered inertial (ei) coordinate system 
and is the default expression for 

eiAngularAccelOfBodyWrtLl_rad_s2_Roll 

a 

OMBD 

bodyAngularAccel_rad_s2 (3) 
bodyAngularAccel_deg_s2 [3] 

Vector of body coordinate angular accelerations of the ownship body axis 
coordinate system with respect to the Locally level (LI) coordinate system (Note: 
WrtLI is the default and is therefore omitted), comprised of the three body axis 
components as defined below. 

P 

PBD 

bodyAngularAccel_rad_s2_Rol 1 
bodyAngularAccel_deg_s2_Rol 1 

Aircraft Roll Acceleration, Body 
coordinate system 

RWD 
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Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

<7 

QBD 

bodyAngul arAcce l_rad_s2_Pi tch 
bodyAngularAccel_deg_s2_Pitch 

Aircraft Rtch Acceleration, Body 
coordinate system 

ANU 




r 

RBD 

bodyAng u 1 a r Ac c e 1 _r ad_s 2_Ya w 
bodyAngul arAcce l_deg_s2_Yaw 

Aircraft Yaw Acceleration, Body 
coordinate system 

ANR 





OMBDE 

bodyAngul arAcce lWrtEi_rad_s2 [3] 
bodyAngularAccelWrtEi_deg_s2 [3] 

Vector of body coordinate angular accelerations with respect to the Earth- 
centered inertial coordinate system, comprised of the three body axis 
components as defined below 

Pb 

PBDE 

bodyAng u 1 a r Ac c e 1 Wr t E i _r ad_s 2 _Ro 1 1 
bodyAngularAccelWrtEi_deg_s2_Roll 

Aircraft Roll Acceleration, Body 
coordinate system 

RWD 




i. 

QBDE 

bodyAngularAccelWrtEi_rad_s2_Pitch 

bodyAngularAccelErtEi_deg_s2_Pitch 

Aircraft Rtch Acceleration, Body 
coordinate system 

ANU 




r. 

RBDE 

bodyAngul arAcce lWrtEi_rad_s2_Yaw 
bodyAngul arAcce lWrtEi_deg_s2_Yaw 

Aircraft Yaw Acceleration, Body 
coordinate system 

ANR 




Kb 


bodyAccelWrtEi_f t_s2 [3] 
bodyAccelWrtEi_m_s2 [3] 

Vector of accelerations of the Cm of the aircraft with respect to and observed 
from the Ei coordinate system (Earth-centered inertial) in the body coordinate 
system This variable includes the gravitation vector. Comprised of the three 
components as defined below. 

UB 

UBD 

bodyAccelWrtEi_f t_s2_X 
bodyAccelWrtEi_m_s2_X 

Longitudinal acceleration (along 
the X-body coordinate) 

FWD 




Vb 

VBD 

bodyAccelWrtEi_f t_s2_Y 
bodyAc c e 1 Wr t E i_m_s 2 _Y 

Right Sideward Acceleration, 
Body coordinate 

RT 




w B 

WBD 

bodyAccelWrtEi_£t_s2_Z 

bodyAccelWrtBi_m_s2_Z 

Downward Acceleration, Body 
coordinate 

DNDN 
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Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

V 


bodyAccelWrtAir_f t_s2 [3] 
bodyAccelWrtAir_m_s2 [3] 

Vector of body coordinate accelerations of the Cm with respect to the mean air 
mass and comprised of the three components as defined below. This variable 
includes the gravitation vector. Comprised of the three components as defined 
below. 

u 


bodyAcce lWr tAi r_f t_s2_X 
bodyAcce lWr tAi r_m_s2_X 

Longitudinal acceleration (along 
the X-body coordinate) 

FWD 




V 


bodyAc c e 1 Wr t Ai r_f t_s2_Y 
bodyAcce lWr tAi r_m_s2_Y 

Right Sideward Acceleration, 
along the Y Body coordinate 

RT 




w 


bodyAc c e 1 Wr t A i r_f t_s 2_Z 
bodyAc c e 1 Wr t A i r_m_s2_Z 

Dowiward Acceleration, along the 
Z Body coordinate 

DNDN 






bodyAcce lWrtGe_ft_8 2 [3] 
bodyAccelWrtGe_m_s2 [31 

Vector of body coordinate Cm velocities with respect to the geocentric Earth 
(Ge) coordinate system. 

Comprised of the three components as defined below. comprised of the three 
components as defined below This variable includes the gravitation vector 
Comprised of the three components as defined below 

UE 


bodyAcce lWrtGe_ft_s2_X 
bodyAccelWrtGe_m_s2_X 

Longitudinal acceleration (along 
the X-body coordinate) 

FWD 






bodyAcce lWrtGe_f t_s2_Y 
bodyAcce lWrtGe_m_s2_Y 

Right Sideward Acceleration, 
along the Y Body coordinate 

RT 




w E 


bodyAc c e 1 Wr t Ge_f t_s 2_Z 
bodyAcce lWrtGe_m_s2_Z 

Downward Acceleration, along the 
Z Body coordinate 

DN 






totalAccelWrtEi_f t_s2 

Magnitude of the inertial 
acceleration vector 

NSC 
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Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


VTDxx 

totalVelocityRateWrtXx_f t_s2 
totalVeloci tyRateWrtXx_m_s2 

Rate of change of speed with 
respect to and observed from Xx, 
where xx is the coordinate system 
as defined in the body of this 
standard. 

INC 







Total velocity (speed) rate of 
change is not the same as 
total acceleration (magnitude 
of the acceleration vector). 

For example, a velocity vector 
that only undergoes a direction 
change shows zero change in 
speed (magnitude) but still 
shows a positive total 
acceleration due to its 
direction chanoe. 







xxAccel_f t_s2 [3] 
xxAcce l_m_s 2 [3] 

General form for the vector of aircraft Cm translational acceleration with respect 
to and observed from the specified (xx) coordinate system comprised of the 
three components as defined below 



xxAccel_f t_s2_X 
xxAcce l_m_s 2_X 

X-axis acceleration in xx 
coordinate system 

+X 






xxAccel_f t_s2_Y 
xxAcce l_m_s2_Y 

Y-axis acceleration in xx 
coordinate system 

+Y 






xxAcce l_ft_s2_Z 
xxAcce l_m_s 2_Z 

Z-axis acceleration in xx 
coordinate system 

+Z 






bodyAccelOf ImuWrtEi_f t_s2 13] 
bodyAccelOf ImuWrtEi_m_s2 (3] 

Vector of true inertial accelerations at the inertial measurement unit (Imu) 
including the effects of the gravitation vector. This variable assumes a perfect 
Imu. 




Comprised of the three body coordinate system components as defined below. 
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Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


AX 

bodyAccelOf ImuWrtEi_f t_s2_X 
bodyAccelOf ImuWrtEi_m_s2_X 

X Acceleration Of aircraft Cm 
(body coordinate) 

Includes the gravitation vector. 

FWD 





AY 

bodyAccelOf ImuWrtEi_f t_s2_Y 
bodyAccelOf ImuWrtEi_m_s2_Y 

Y Acceleration Of aircraft Cm 
(body coordinate) 

Includes the gravitation vector 

RT 





A Z 

bodyAccelOf ImuWrtEi_f t_s2_Z 
bodyAccelOf ImuWrtEi_m_s2_Z 

Z Acceleration Of aircraft Cm 
(body coordinate) 

Includes the gravitation vector. 

DN 






bodySensedAccelOf ImuWrtEi_f t_s2 [3] 
bodySensedAccelOf ImuWrtEi_m_s2 [3] 

Vector of sensed inertial accelerations at the inertial measurement unit (Imu) 
including the effects of the gravitation vector. This variable includes any senor 
scale, bias and noise.. 

Comprised of the three body coordinate system components as defined below. 



bodySensedAccelOf ImuWrtEi_f t_s2_X 
bodySensedAccelOf ImuWrtEi_m_s2_X 

X Acceleration Of aircraft Cm 
(body coordinate) 

Includes the gravitation vector. 

FWD 






bodySensedAccelOf ImuWrtEi_f t_s2_Y 
bodySensedAccelOf ImuWrtEi_m_s2_Y 

Y Acceleration Of aircraft Cm 
(body coordinate) 

Includes the gravitation vector 

RT 






bodySensedAccelOf ImuWrtEi_ft_s2_Z 
bodySensedAccelOf ImuWrtEi_m_s2_Z 

Z Acceleration Of aircraft Cm 
(body coordinate) 

Includes the gravitation vector 

DN 






bodyAccelOf Pi lotWrtEi_ft_s2 [3] 
bodyAccelOf Pi lotWrtEi_m_s2 [3] 

Vector of inertial accelerations at the pilot reference point, in the body coordinate 
system, comprised of the three components as defined below. 
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Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


AXP 

bodyAc c e 1 Of P i 1 o tWr t E i _f t _s 2_X 
bodyAccelOf Pi lotWrtEi_m_s2_X 

X Acceleration Of Pilot reference 
point (body coordinate) 

FWD 





AYP 

bodyAccelOf Pi lotWrtEift_s2_Y 
bodyAccelOf Pi lotWrtEi_m_s2_Y 

Y Acceleration Of Pilot reference 
point(body coordinate) 

RT 





AZP 

bodyAccelOf Pi lotWrtEi_f t_s2_Z 
bodyAccelOf PilotWrtEi_m_s2_Z 

Z Acceleration Of Pilot reference 
point(body coordinate) 

DN 





GVBODY 

[3] 

bodyLocalGravitation_f t_s2 [3] 
bodyLocalGravitation_m_s2 [3] 

Local gravitation vector in the body coordinate system. 


GVBODYX 

bodyLocalGr avi tat ion_f t_s2_X 
bodyLoc a 1 Gr a vi t a t ion_f t_s 2_X 

X axis component 

FWD 





GVBODYY 

bodyLocalGr avi tat ion_f t_s2_Y 
bodyLoc a 1 Gr avi t at i on_f t_s 2_Y 

Y axis component 

RT 





GVBODYZ 

bodyLoc a 1 Gr a v i t a t ion_f t_s 2_Z 
bodyLocalGr avi tat ion_f t_s2_Z 

Z axis component 

DN 





GVGE [3] 

geLocalGravi tat ion_ft_s2 [3] 
geLocalGravitation_m_s2 [3] 

Local gravitation vector in the ge (geocentric Earth) coordinate system. 


GVGEX 

geLocalGravi ta t ion_f t_s2_X 
geLocalGravitation_ft_s2_X 

X axis component 

FWD 





GVGEY 

geLocalGravi tat ion_f t_s2_Y 
geLocalGravi tat ion_f t_s2_Y 

Y axis component 

RT 





Annex A Page 23 of 54 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

152 of 
343 


ANSI/AIAA S-119 


Annex A. Standard Variable Names 


Symbol 

Short Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


GVGEZ 

geLocalGravitation_f t_s2_Z 
geLocalGravitation_f t_s2_Z 

Z axis component 

DN 





GVEI[3] 

eiLocalGravitation_f t_s2 [3] 
eiLocalGravitation_m_s2 [3] 

Local gravitation vector in the ei (Earth centered inertial) coordinate system. 


GVEIX 

eiLocalGravitation_f t_s2_X 
eiLocalGravitation_f t_s2_X 

X axis component 

FWD 





GVEIY 

eiLocalGravitation_f t_s2_Y 
eiLocalGravitation_f t_s2_Y 

Y axis component 

RT 





GVEIZ 

e i Loc a 1 Gr a v i t a t i on_f t_s 2_Z 
eiLocalGravitation_f t_s2_Z 

Z axis component 

DN 





G 

localGravi ty_f t_s2 
localGravity_m_s2 

Acceleration Due To Gravity (at 
the vehicle altitude), in the LI 
coordinate system. 

DN 





Table A 4 — Vehicle air data 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

a 

ALFA 

angleOf Attack_deg 
ang 1 eOf At tack_r ad 

Angle Of Attack, Body coordinate 

ANU 


-7T _ 
180 

+/r 

+180 

p 

BETA 

ang 1 eOf S i de s 1 i p_deg 
ang 1 eOf S i de s 1 ip_rad 

Sideslip Angle, Body coordinate 

ANL 


-7T _ 
180 

+/T 

+180 

a 

ALFD 

angleOf AttackRate_rad_s 

Angle Of Attack Rate, Body 
coordinate 

ANU 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

P 

BETD 

ang 1 eOf S ide s 1 i pRa te_r ad_s 

Sideslip Angle Rate 

ANL 




sin a 

SALPH 

s i neAng 1 eOf Attack 

Sine Of Angle Of Attack 

ANU 


-1.0 

1.0 

cos a 

CALPH 

cosineAngleOf Attack 

Cosine Of Angle Of Attack 

ANU 


-1.0 

1.0 

sin p 

SB ETA 

sineAngleOf Sideslip 

Sine Of Sideslip Angle 

ANL 


-1.0 

1.0 

cos p 

CBETA 

cosineAngleOf Sideslip 

Cosine Of Sideslip Angle 

ANL 


-1.0 

1.0 

VcAL 

VCAL 

calibratedAirspeed_nmi_h 

Calibrated Air Speed, knots 

FWD 




Veq 

VEQ 

equivalentAirspeed_nmi_h 

Equivalent Air Speed 

FWD 




VlND 

VCAL 

indicatedAirspeed_nmi_h 

Calibrated Air Speed, 

FWD 




V 

VRW 

t rueAi r speed_f t_s 
trueAi rspeed_m_s 
trueAirspeed_nmi_h 

Vehicle Velocity relative to the 
local wind (true airspeed) 

FWD 




q 

QBAR 

dynamicPressure_lbf_f t2 
dynami cPres sure_N_m2 

Dynamic Pressure 

NSC 




q< 

QBARC 

impactPressure_lbf_f t2 
impactPressure_N_m2 

Impact Pressure 

NSC 




P 

RHO 

a i rDens i ty_lbm_f 1 3 
a i rDen s i ty_kg_m 3 

Air Density, At Altitude of the 
aircraft 

NSC 





DENALT 

den s i tyAl t i tude_f t 
den s i tyAl t i t ude_m 

Density altitude 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

a 

SOUND 

speedOf Sound_f t_s 
speedOf Sound_m_s 

Velocity Of Sound At Altitude of 
the aircraft 

NSC 




Ttotr 

TR 

totalTempRatio 

totalTempRatio 

Total Temperature Ratio 

NSC 




Ptotr 

PR 

total PressureRatio 
total PressureRatio 

Total Pressure Ratio 

NSC 




Tamb 

TAMB 

ambientTemperature_dgC 

ambientTemperature_dgK 

Ambient Temperature at altitude 

NSC 




Pamb 

PAMB 

ambientPressure_lbf_f t2 
ambi en t Pre s sur e_N_m2 

Ambient Pressure at altitude 

NSC 




Pambr 

PAMBR 

ambient PressureRatio 

Ratio Of ambient pressure at 
altitude to sea level ambient 
pressure 

NSC 




Tambr 

TAMBR 

ambientTemperatureRatio 

Ratio Of ambient temperature at 
altitude to sea level ambient temp 

NSC 




tr 

TTOT 

totalTemp_dgC 

totalTemp_dgK 

Total Temperature at altitude 

NSC 




Pt 

PTOT 

total Pressure_lb£_f t2 
total Pressure_N_m2 

Total Pressure at altitude 

NSC 





TAMB 

ambi en tTempera tureAtAl t_dgK 
ambientTemperatureAtAlt_dgR 
ambientTemperatureAtAlt_dgC 

Ambient temperature, at the 
altitude of the Cm 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


TTOT 

totalTemperatureAtAlt_dgK 
totalTemper atureAtAl t_dgR 
totalTemper atureAtAl t_dgC 

Total temperature at the altitude of 
the Cm 






ALT_SET 

inst rumen tAltimeterSetting_inchMercury 

Cockpit Altimeter setting 
(Kohlsman window) 

29.92 is 
standard day 





P_ALT 

pressureAl t i tude_f t 
pressureAl t i tude_m 

Pressure altitude at the Cm 






RHO_SL 

seaLevelAirDensity_lbm_f t3 

Air density at sea level 






TAMB_SL 

seaLevelAmbientTemp_dgK 

seaLevelAmbientTemp_dgC 

Ambient temperature at mean sea 
level 






PAMB_SL 

seaLevel AmbientPressure_lbf _f t2 
seaLevelAmbientPressure_N_m2 

Ambient pressure at sea level 






Table A. 5 — .Atmospheric disturbances and turbulence 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


WIND_SPE 

ED 

meanAirMassSpeed ft s 

T otal velocity of mean wind 





meanAirMassSpeed m s 


WIND_DIR 

ECTION 

meanAirMassDirection_deg 

Mean wind direction 

Wind blowing 
FROM North 




V„ 

VTWS 

totalWindSpeed ft s 

Total Wind Speed (mean wind 
plus turbulence) 

NSC 




totalWindSpeed m s 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

-WT„ 


HTurbulenceVelocityWrtGe ft s[3] 
llTurbulenceVelocityWrtGems [3] 

Vector of locally level coordinate wind turbulence velocities with respect to the 
geocentric earth (Ge) fixed coordinate system. 

Comprised of the three components as defined below 




Note. This vector is designed to be transformed from the GRA 
oertubation velocities GRAM 07 outputs the wind oertubation v 

usmall (+ East) 

vsmall (+ North) 

wsmall (+ UP) 

Therefore: 

M 07 small wind 
“ctor 

1 1 turbulenceVelocityWrtGe m s X = vsmall 


HturbulenceVelocityWrtGe m s Y = usmalSi 


11 turbulenceVelocityWrtGe m s Z = -wsmall 


N "r, 

NSMALL 

1 lTurbulenceVelocityWrtGe ft s X 
HTurbulenceVelocityWrtGe m 

X-vetocity T urb. Component 

to the North 




■ 

ESMALL 

1 lTurbulenceVelocityWrtGe ft s Y 
1 lTurbul enceVeloci tyWr tGe_m_s_Y 

Y-velocity Turb. Component 

to the East 




D "r, 

DSMALL 

1 lTurbulenceVelocityWrtGe ft s Z 
1 lTurbulenceVelocityWrtGe m 

Z-velocity T urb. Component 

to downward 




— 7*106 

VELBWT 

bodyTurbulenceVelocityWrtGe ft sfJB 
bodyTu rbu lenceVeloci ty Wr t G e_m_s [ 3 ] 

Vector of body coordinate translational turbulence velocities comprised of the 
three components as defined below. 

Uiutb 

UBTURB 

bodyTurbulenceVelocityWrtGe ft s X 
bodyTu rbu 1 e nc eVe 1 oc i tyWr tG e_m_ s_X 

X-velocity T urb. Component, Body 
coordinate 

FWD (tailwind) 




Vturti 

VBTURB 

bodyTurbulenceVelocityWrtGe ft s Y 
bodyTurbulenceVeloci tyWrtGem 3 Y 

Y-velocity Turb. Component, Body 
coordinate 

RT 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

WTurt) 

WBTURB 

bcdyTurbulenceVelocityWrtGe ft s Z 
bodyTurbulenceVelocityWrtGe_m_s_Z 

Z-velocity T urb. Component, Body 
coordinate 

ON 




v wu. 

VELMW 

UVelocityOfMeanAirMassWrtGe ft sI3] 
1 IVelocityOf MeanAirMassWrtGe_m_s [3] 

Vector of locally level coordinate mean wind translational velocities comprised of 
the three components as defined below. 




Note This vector is designed to be transformed from the GRAf 
velocities GRAM 07 outputs the mean wind velocity vector: 

uraean (+ East) 

vine an (+ North) 

Hhsig^HidH 

Therefore 

A 07 wind model 

UVelocityOfMeanAirMassWrtGe m s X = vmean 


UVelocityOfMeanAirMassWrtGe m s Y = umean 


UVelocityOfMeanAirMassWrtGe m s Z = -wtnean 


M,| 

NMEAN 

UVelocityOfMeanAirMassWrtGe ft 
UVelocityOfMeanAirMassWrtGe m s X 

X-velocity Component, locally 
level coordinate system 

to the North 




1858 

EMEAN 

1 IVelocityOf MeanAirMassWrtGeft 
UVelocityOfMeanAirMassWrtGe m 

Y-velocity Component, locally 
level coordinate system 

to the East 




m 

DMEAN 

1 IVeloci tyOf MeanAi rMassWr tGe_f t_s_Z 
. t'CityOf MeanAirMassWrtGe m 

Z-velocity Component locally 
level coordinate system 

to downward 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

'■W 

VELMWB 

bodyVeloci tyOf MeanAirMassWrtGe ft s(3] 
bodyVeloci tyOfMeanAirMassWrtGeu 

Vector of body coordinate system mean wind translational wind velocities 
comprised of the three components as defined below. 





Note This vector is designed to be the GRAM 07 wind model mean velocities 
transformed into the body coordinate system 


UMEANB 

bodyVeloci tyOfMaanAirMassWrtGe f ! 
bodyVeloci tyOf MeanAirMassW: 

X-velocrty Component, body 
coordinate system 

FWD (tailwind) 




v x 

VMEANB 

bodyVelocityOfMeanAirMassW: t 
bodyVeloci tyOf MeanAirMassWrtGe n 

Y-velocity Component, body 
coordinate system 

To the RT 




M b 

WMEANB 

bodyVeloci tyOfMeanAirMassWi 
bodyVelocityOfMeanAirMassW: t 

Z-velocity Component, body 
coordinate system 

DN 




— 7W 

VTW 

bodyWindVe 1 oc i tyWrtGe f t s [ 3 ] 
bodyWindVeloci tyWrt 

Vector of the body coordinate system of net wind velocities impinging on the 
aircraft at the Cm This would include mean air mass motion and any 

Comprised of the three components as defined below 

Note Winds are always with respect to and observed from an Earth-fixed 
reference frame This vector is with respect to the geocentric Earth (Ge)fixed 
coordinate system. 

Utw 

UBTWX 

bodyWindVe loci tyWr tG 
bodyWindVeloci tyW: 

Net wind velocity impinging on the 
vehicle in the X body axis 

FWD (tailwind) 





Net wind is the mean air mass 
plus any turbulence, shears, or 
other wind disturbances. 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

v,„ 

VBTWY 

bodyWindVelocityWrCG 
bodyWi ndVe 1 oc i ty w : 

Net wind velocity impinging on the 
vehicle in the Y body axis 

IS 





Net wind is the mean air mass 
plus any turbulence, shears, or 
other wind disturbances 

Wr„ 

VBTWZ 

bodyWindVeloci tyWrtGef t_s_Z 
bodyWindVeloci tyWrtGe m s 

Net wind velocity impinging on the 
vehicle in the Z body axis 

DN 





Net wind is the mean air mass 
plus any turbulence, shears, or 
other wind disturbances. 



bodyAngularRateTurbulenceWrtLl_deg_s [ 3 ] 
bodyAngularRat.eTurbulenceWrt.Ll rad s [3] 

Vector of angular turbulence velocities comprised of the three body coordinate 
system components as defined below. 


Note: T urbulence angular rate is always with respect to and observed from the 
locally level (LI) reference frame 


PTURB 

bodyAngularRateTurbulenceWrtLl_deg_s_Roll 
bodyAnqularRateTurbulenceWrtLl rad s Roll 

Body coordinate roll turbulence 

The turbulence 
would move the 
aircraft right 
wing down 





QTURB 

bodyAngularRateTurbulenceWrtLl_deg_s_Pitch 
bodyAnqularRateTurbulenceWrtLl rad s Pitch 

Body coordinate pitch turbulence 

The turbulence 
would move the 
aircraft nose up 





RTURB 

bodyAngularRateTurbulenceWrtLl_deg_s_Yaw 
bodyAngularRateTurbulenceWrtLl rad s 

Body coordinate yaw turbulence 

The turbulence 
would move the 
aircraft nose 
right 
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T able A 6 — Vehicle physical characteristics 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

1 


bodyMomentOf Inert ia_slugft2 [3,3] 
bodyMomentOf Inert ia_kgm2 [3,3] 

Matrix of the total moments of inertia of the aircraft This is wrth respect to the 
Cm and includes everything in or attached to the aircraft (stores, passengers, 
crew, fuel, etc ) It is comprised of the components below 

Ixx -Ixy -Izx 

-Ixy Iyy -Iyz 

-Izx -IyZ Izz 

/, 

XIXX 

bodyMomentOf Inert ia_8 lug ft 2_X 
bodyMomentOf I ner t i a_kgm2_X 

Vehicle Roll Moment Of Inertia 
about Cm, body coordinate 
system 

NSC 




ly 

XI YY 

bodyMomen tOf I ne r t i a_8 1 ug f t 2_Y 
bodyMomentOf Inert ia_kgm2_Y 

Vehicle Pitch Moment Of Inertia 
about Cm, body coordinate 
system 

NSC 




h 

XI ZZ 

bodyMomentOf Inert ia_slugf t2_Z 
bodyMomentOf Inert ia_kgm2_Z 

Vehicle Yaw Moment Of Inertia 
about Cm, body coordinate 
system 

NSC 




l*z 

XIZX 

body Produc tOf Inert! a_s 1 ug f 1 2_ZX 
bodyProductOf Inertia_kgm2_ZX 

Vehicle ZX Cross Product Of 
Inertia about Cm, body coordinate 
system 

NSC 





XIXY 

body Produc tOfInertia_slugft 2_XY 
bodyProductOf Inert ia_kgm2_XY 

Vehicle XYy Cross Product Of 
Inertia about Cm, body coordinate 
system 

NSC 




lyz 

XI YZ 

bodyProductOf Inert ia_slugft2_YZ 
bodyProductOf Inertia_kgm2_YZ 

Vehicle YZ Cross Product Of 
Inertia about Cm. body coordinate 
system 

NSC 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


MrcPos 

vrsPo3ition0f Mrc_f t [3] 
vrsPositionOf Mrc_m [3] 

Vector of the location of the moment reference center (Mrc) of the aircraft in the 
vehicle reference system (vrs). Comprised of the three components as defined 
below. This vector is used to define the fixed physical location of the moment 
reference center in the vehicle. Note that the vrs definition is specific to each 
vehicle. 


XMrc 

vrsPositionOf Mrc_f t 
vrsPositionOf Mrc_m 

X Mrc Position 






YMrc 

vr s Pos i t i onOf M r c_f t 
vrsPositionOfMrc_m 

Y Mrc Position 






ZMrc 

vrsPositionOfMrc_f t 
vrsPositionOf Mrc_m 

Z Mrc position 





Acg 

DCG 

bodyPositionOf CmWrtMrc_f t [3] 

Vector of the location of the Cm with respect to the moment reference center 
(Mrc) of the aircraft in the body coordinate system. Comprised of the three 
components as defined below. This vector is used to define the location of the 
Cm vtfiich moves Wrt to the fixed moment reference center in the vehicle. Note 
that vrs Pos it ionOf Mrc locates the Mrc in the vehicle. 

AXcg 

DXCG 

body Pos i t ionOf CmWr tMr c_f t_X 
body Pos i t ionOf CmWr tMr c_m_X 

X Cm position 

Cm forward of 
the Mrc 




AYcg 

DYCG 

body Pos i t ionOf CmWr tMrc_f t_Y 
bodyPos i t ionOf CmWr tMr c_m_Y 

Y Cm position 

Cm to the right 
(out the right 
wing) of the Mrc 




AZcg 

DZCG 

body Pos i t ionOf CmWr tMr c_f t_Z 
bodyPos i t ionOf CmWr tMr c_m_Z 

Z Cm position 

Cm below the 
Mrc 




m 

XMASS 

totalMass_slug 

totalMass_kg 

Total Mass Of Vehicle (including 
Fuel, crew, cargo, stores, 
passengers, etc.) 

NSC 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

W 

WEIGHT 

g ros sWe ight_lbf 
g r o s s We i gh t_N 

Aircraft Gross Weight 
(mass*gravity), including all fuel, 
occupants, stores, etc. 

NSC 




S 

AREA 

ref erenceWingArea_f t2 
ref erenceWingArea_m2 

Reference Wing Area 

NSC 




b 

SPAN 

ref erenceWingSpan_f t 
ref erenceWingSpan_m 

Reference Wing Span 

NSC 




c 

CHORD 

ref erenceWingChord_f t 
ref erenceWingChord_m 

Mean Aerodynamic Chord 
(reference wing chord) 

NSC 






engineMomentOf Inertia_slugf t2 [3,3] 
eng ineMomentOf Inert ia_kgm2 [3,3] 

Matrix of the moments of inertia of the Rotating engine, for an engine with the 
propeller, includes the propeller and drive train. This is w.r.t the rotational axis 
of the engine For multi-engine vehicles is for one engine. It is comprised of the 
components below. 

Iexx -Iexy -Iezx 

-Iexy Ieyy -Ieyz 

*Iezx -Ieyz Iezz 

kx 

IEXX 

engineMomentOf Inertia_slugft2_X 
engineMomentOf Inert ia_kgm2_X 

Moment of inertia about the X-axis 
Of Rotating Eng, for an engine 
with the propeller, includes the 
propeller 

This is w.r.t the rotational axis of 
the engine 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

fey 

IEYY 

engineMomentOf Inert ia_slugf t2_Y 
engineMomentOf Inert ia_kgm2_Y 

Moment of inertia about the Y-axis 
Of Rotating Eng, for an engine 
with the propeller, includes the 
propeller 

This isw.r.t the rotational axis of 
the engine 





fez 

IEZZ 

eng i neMomen t Of Inert! a_s 1 ug f 1 2_Z 
engineMomentOf Inertia_kgm2_Z 

Moment of inertia about the Z-axis 
Of Rotating Eng, for an engine 
with the propeller, includes the 
propeller 

This isw.r.t the rotational axis of 
the engine 





fexz 

IEXZ 

engineProductOf Inert ia_slugf t2_XZ 
engineProductOf Inert ia_kgm2_XZ 

Product of inertia about the XZ- 
axis Of Rotating Eng, for an 
engine wth the propeller, includes 
the propeller 

This isw.r.t the rotational axis of 
the engine 





fexy 

IEXY 

engineProductOf Inert ia_slugft2_XY 
engineProductOf Inertia_kgm2_XY 

Product of inertia about the XY- 
axis Of Rotating Eng, for an 
engine wth the propeller, includes 
the propeller 

This isw.r.t. the rotational axis of 
the engine 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

feycr 

IEYZ 

eng ineProductOf Inert ia_slugf t2_YZ 
engineProductOf Inert ia_kgm2_YZ 

Product of inertia about the YZ- 
axis Of Rotating Eng, for an 
engine with the propeller, includes 
the propeller 

This is w.r.t the rotational axis of 
the engine 







fuel InTank_lbm [number of fuel tanks] 
fuel InTank_kg [number of fuel tanks] 

Vector of fuel weight by tank. 
Each aircraft tank is normally 
numbered and the vector should 
be ordered according to fuel tank 
number. In the absence of tank 
numbering the convention of port 
to starboard, upper to lower, then 
front to rear should be used. 







fuelTankCentroid_ft [number of fuel tanks, 3] 
fuelTankCentroid_m [number of fuel tanks, 3] 

Matrix used to locate the centoids 
of the fuel tanks. Each aircraft 
tank is normally numbered and 
the matrix should be ordered 
according to fuel tank number 
The second component is the x, y 
and z moment arms from the 
moment reference center to the 
tank centroid in the structural 
coordinate system. In the 
absence of tank numbering the 
convention of port to starboard, 
upper to lower, then front to rear 
should be used. 

Tank centroid 
behind, right, 
and below the 
moment 
reference 
center. 





Table A. 7 — Vehicle control position 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Standard naming convention for crew control inputs 

"Pos" indicates a position input 

"Rate" indicates the derivative of the position input 
"Accel" indicates the derivative of the rate 
"Force" indicates the force input 

Control positions for a vehicle are often uniquely defined for that vehicle, 
therefore the: 

Description 

Positive Sign Convention 
Initial Value 
Min Value 
Max Value 

definitions may all change based on the particular vehicle. 

The table below shall be used as default descriptions and values when 
they are not otherwise explicitly defined for the vehicle. 

•K 


pilotControlPos_deg_long 
p i 1 o t Con t r o 1 Po s_r ad_ 1 ong 

Longitudinal control position of the 
pilot. 

AFT 

0= vertical when 
vehicle body is 
level (pitch and 
roll attitude = 0) 






pi lotControlRate_deg_s_long 
pi lotControlRate_rad_s_long 

Rate of the pilot Longitudinal 
control movement. 

Moving aft 






pilotControlAccel_deg_s2_long 
pi lotCon t rol Acce l_r ad_s2_long 

Acceleration of the pilot 
Longitudinal control movement. 

Accelerating aft 






pi lotControl Force_lbf _long 
pi lotControlForce_N_long 

Longitudinal control force of the 
pilot 

Aft force 




The convention and examples above apply to all pilot and copilot controls defined below 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



pi lotControl Pos_deg_l at 
pi lotControl Pos_rad_l at 

Lateral control position of the pilot 

LEFT 

0= vertical when 
vehicle body is 
level (pitch and 
roll attitude = 0) 






pi lotControl Pos_deg_avg Pedal 
pi lotControl Pos_rad_avg Pedal 

Net Directional control position of 
the pilot. Normally, left pedal + 
right pedal 

Left Pedal in or 
counter 
clockwise twist 
of a sidestick 






pilotControlPos_deg_rtPedal 
pi lotControl Pos_rad_rt Pedal 

Right Directional control position 
of the pilot. 

NEGATIVE for 
Pedal in 

0= pedal full aft 



0.0 



pi lotControl Pos_deg_l tPeda 1 
pi lotControl Pos_rad_l t Pedal 

Left Directional control position of 
the pilot. 

Pedal in. 

0= pedal full aft 


0.0 




p i 1 o t Con t r o 1 Pos_d eg_co 1 1 e c t i ve 
pilotControlPos_rad_collective 

Pilot collective control position. 

UP 

0 = full down 


0.0 




pilotControlPos_deg_avgThrottle 
pi lotControlPos_rad_avgThrottle 

Average pilot throttle control 
position. 

FWD 

0= full aft Wo 
thrust reversing. 
Thrust reversing 
is negative 






pilotControlPos_deg_throttle [number of 
engines] 

pilotControlPos_rad_throttle [number of 
engines] 

Individual pilot throttle control 
positions. Order is outboard port 
(left) to outboard starboard 

FWD 

0= full aft Wo 
thrust reversing. 
Thrust reversing 
is negative 





Annex A Page 38 of 54 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

167 of 
343 


ANSI/A1AA S-119 


Annex A. Standard Variable Names 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



cop i 1 o t Con t r o 1 Pos_d eg_ 1 ong 
copilot Control Pos_rad_long 

Longitundal control position of the 
copilot. 

AFT 

0= vertical when 
vehicle body is 
level (pitch and 
roll attitude = 0) 






copilotControlPos_deg_lat 
copi lot Control Pos_r ad_l at 

Lateral control position of the 
copilot. 

LEFT 

0= vertical when 
vehicle body is 
level (pitch and 
roll attitude = 0) 






copilotControlPos_deg_avg Pedal 
copi lotControlPos_rad_avg Pedal 

Net Directional control position of 
the copilot. Normally, Left pedal + 
right pedal 

Left Pedal in or 
counter 
clockwise twist 
of a sidestick 






copi lot Control Pos_deg_rt Pedal 
copilotControlPos_rad_rtPedal 

Right Directional control position 
of the copilot. 

NEGATIVE for 
Pedal in 

0= pedal full aft 



0.0 



copi lotControl Pos_deg_l tPedal 
copi lotControl Pos_rad_l t Pedal 

Left Directional control position of 
the copilot. 

Pedal in. 

0= pedal full aft 


0.0 




copi lotControl Po8_deg_collective 
copi lot ControlPos_rad_collective 

Copilot collective control position. 

UP 

0 = full down 


0.0 




copi lotControl Pos_deg_avgThrot t 1 e 
copi lotControl Pos_rad_avgThrot t 1 e 

Average copilot throttle control 
position. 

FWD 

0= full aft Wo 
thrust reversing. 
Thrust reversing 
is negative 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



copilotControlPos_deg_throttle [number of 
engines] 

copilotControlPos_rad_throttle [number of 
engines] 

Individual copilot throttle control 
positions. Order is outboard port 
(left) to outboard starboard 

FWD 

0= full aft Wo 
thrust reversing. 
Thrust reversing 
is negative 






control Pos_deg_avgThrot tie 
con t ro 1 Po s_r ad_a vgTh r o t t 1 e 

Average pilot and copilot throttle 
control position 

FWD 

0= full aft Wo 
thrust reversing. 
Thrust reversing 
is negative 






control Pos_deg_avgPropel lor 
con t ro 1 Po s_r ad_a vg Propellor 

Average pilot and copilot propeller 
blade pitch control position. 

FWD 

0=flat pitch, 
Thrust reversing 
is negative 






control Pos_deg_propel lor [number of engines] 
controlPos_rad_propellor [number of engines] 

Individual propeller blade pitch 
control position Order is outboard 
port (left) to outboard starboard. 

FWD 

0=flat pitch, 
Thrust reversing 
is negative 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Standard naming convention for control surfaces 

"Pos" indicates a control surface position 

"Rate" indicates the derivative of the control surface position 

"Accel' indicates the derivative of the control surface rate 

"HinqeMoment" indicates the hinge moment on the control surface 
(sign convention = ♦ deflection results in ♦ hinge moment) 

Control surface positions for a vehicle are often uniquely defined for that vehicle, 
therefore the: 

Description 

Positive Sign Convention 
Initial Value 
Min Value 
Max Value 

definitions may all change based on the particular vehicle 

The table below shall be used as default descriptions and values when 
they are not otherwise explicitly defined for the vehicle. 

5tef„ 


controlSurf acePos_deg_TEF [number of trailing 
edge flap control surfaces] 

controlSurf acePo8_rad_TEF [number of trailing 
edge flap control surfaces] 

Vector of trailing edge flap 
positions, one for each surface 
deflected Order is outboard port 
(left) to outboard starboard 

TED 

0 deflection is 
flap retracted 






controlSurf aceRate_deg_8_TEF [number of 
trailing edge flap control surfaces] 
controlSurf aceRate_rad_s_TEF [number of 
trailing edge flap control surfaces] 

Vector of trailing edge flap 
deflection rates, one for each 
surface Order is outboard port 
(left) to outboard starboard 

TED 






controlSurf aceAccel_deg_s2_TEF [number of 
trailing edge flap control surfaces] 
controlSurf aceAccel_rad_s2_TEF [number of 
trailing edge flap control surfaces] 

Vector of trailing edge flap 
deflection accelerations, one for 
each surface Order is outboard 
port (left) to outboard starboard 

TED 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



controlSurf aceHingeMoment_ftlbf_TEF [number 
of trailing edge flap control surfaces] 
controlSurf aceHingeMoment_Nm_s_TEF [number of 
trailing edge flap control surfaces] 

Vector of the hinge moments on 
the trailing edge flap, one for each 
surface Order is outboard port 
(left) to outboard starboard 

+ = TEU 
moment 
(positive 
deflection 
results in 
positive 
moment) 




The convention and examples above apply to all control surface positions defined below 

&TEF n 


controlSurf acePos_deg_TEF [number of leading 
edge flap control surfaces] 

controlSurf acePos_rad_TEF [number of leading 
edge flap control surfaces] 

Vector of trailing edge flap (TEF) 
positions, one for each surface 
deflected Order is outboard port 
(left) to outboard starboard 

TED 




Stef 


controlSurf acePos_deg_avgTEF 
con t ro 1 Su r f ac e Po s_r ad_a vgTE F 

T railing edge flap deflection 
(TEF). Average for all trailing 
edge flap surfaces 

TED 

0 deflection is 
flap retracted 






controlSurf acePos_deg_di f f TEF 
controlSurf acePos_rad_dif fTEF 

Differential trailing edge flap 
(DTEF) deflection (left deflections 
{+=TED} -right deflections 
{+=TED}) 

LT TED 
(R\MD moment) 




Aef„ 


controlSurf ace Pos_deg_LEF [number of leading 
edge flap control surfaces] 

controlSurf acePo8_rad_LEF [number of leading 
edge flap control surfaces] 

Vector of leadng edge flap (LEF) 
positions, one for each surface 
deflected Order is outboard port 
(left) to outboard starboard 

LED 




5lef 


controlSurf acePos_deg_avgLEF 
controlSurf acePos_rad_avgLEF 

Leading edge flap/slat deflection 
Average for all deflected leading 
edge flap/slat surfaces 

LED 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

®*IEF 


controlSurf acePos_deg_di f f LEF 
controlSurf acePos_rad_diff LEF 

Differential leading edge flap 
(LEF) deflection (left deflections- 
right deflections) 

LT LED 

(RVWD moment) 




55P n 


controlSurf acePos_deg_spoiler [number of 
spoiler control surfaces] 

controlSurf acePo8_rad spoiler [number of 
spoiler control surfaces] 

Vector of spoiler control surface 
positions, one for each surface 
deflected Order is outboard port 
(left) to outboard starboard 

TEU 




5s p 


controlSurf acePos_deg_avgSpoiler 
controlSurf acePos_rad_avgSpoi 1 er 

Spoiler deflection Average for all 
deflected spoilers (sum of 
positions/number of surfaces) 

TEU 




5&SP 


controlSurf acePos_deg_diff Spoiler 
controlSurf acePos_rad_dif fSpolier 

Differential spoiler control surface 
position (right deflections-left 
deflections) 

RT TEL) 
(RVJD moment) 




K 


controlSurf acePo8_deg_aileron [number of 
aileron control surfaces] 

controlSurf acePo8_rad_aileron [number of 
aileron control surfaces] 

Vector of aileron control positions, 
one for each surface deflected 
Order is outboard port (left) to 
outboard starboard 

TEU 






controlSurf acePos_deg_dif f Aileron 
controlSurf acePos_rad_di f f Ai 1 eron 

Differential aileron deflection, 
(right deflections-left deflections) 

Right aileron 
TEU 

(R\M) moment) 






controlSurf acePos_deg_aileronTab [number of 
aileron control surfaces, number of tabs] 

controlSurf acePos_rad_aileronTab [number of 
aileron control surfaces, number of tabs] 

Array of aileron tab control 
positions (i) for each surface 
deflected (n). Order is outboard 
port to outboard starboard 

TEU 




5 


controlSurf acePos_deg_avgAileronTab 
controlSurf acePos_rad_avgAileronTab 

Average aileron tab deflection 
(sum of positions/number of 
surfaces) 

TEU 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



controlSurf acePos_deg_dl f f Ai 1 eronTab 
controlSurf acePos_rad_diff Ail eronTab 

Differential aileron tab deflection 
(right tab deflections- left tab 
deflections) 

RT Aileron Tab 
TEU 

(RWD moment) 




5p n 


controlSurf acePos_deg_rudder (number of 
rudder control surfaces] 

controlSurfacePo8_rad_rudder (number of 
rudder control surfaces] 

Vector of rudder control positions, 
one for each surface deflected 
Order is outboard port (left) to 
outboard starboard 

TEL 




8r 


controlSurf acePos_deg_avgRudder 
controlSurf acePo8_rad_avgRudder 

Average rudder deflection (sum of 
positions/number of surfaces) 

TEL 




S 


controlSurf ace Pos_deg _di f f Rudder 
controlSurf acePos_rad_diff Rudder 

Differential rudder deflection (right 
deflections-left deflections) 

RT Rudder TEL 
(ANR moment) 




5Rtab ni 


controlSurf acePos_deg_rudderTab [number of 
rudder control surfaces, number of tabs] 

controlSurf acePos_rad_rudderTab [number of 
rudder control surfaces, number of tabs] 

Array of rudder tab control 
positions (i) for each surface 
deflected (n). Order of tabs is 
upper to lower 

TEL 




5rm b 


controlSurf acePos_deg_avgRudderTab 
controlSurf acePos_rad_avgRudderTab 

Average rudder tab deflection 
(sum of positions/number of 
surfaces) 

RT RudderTab 
TEL 

(ANR moment) 




^®Rtao 


controlSurf acePos_deg_dlf f RudderTab 
controlSurf acePos_rad_di f f RudderTab 

Differential rudder tab deflection 
(right deflections-left deflections) 

RT RudderTab 
TEL 

(ANR moment) 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

8e„ 


controlSurf acePos_deg_e levator [number of 
elevator control surfaces] 

controlSurf acePos_rad_e levator [number of 
elevator control surfaces] 

Vector of elevator (or 
stabilizer/stabilator) control 
positions, one for each surface 
deflected. Order is outboard port 
(left) to outboard starboard. 

TEU 




5e 


controlSurf acePos_deg_avgEleva tor 
control Surf acePos_r ad_avg E 1 e va tor 

Average elevator (or 
stabilizer/stabilator) deflection ) 
(sum of positions/number of 
surfaces) 

TEU 






controlSurf acePos_deg_d i f f E 1 evator 
controlSurf acePos_rad_diff Elevator 

Differential elevator deflection 
(right deflections-left deflections) 

Right control 
TEU 

(RWD moment) 




SBab n , 


controlSurf acePos_deg_elevatorTab [number of 
elevator tab control surfaces, number of 
tabs] 

controlSurf acePos_rad_elevatorTab [number of 
elevator tab control surfaces, number of 
tabs] 

Array of elevator (or 
stabilizer/stabilator) tab positions 
(i) for each surface (n). Order is 
outboard port (left) to outboard 
starboard per control surface. 

TEU 




SEtab 


controlSurf acePos_deg_avgElevatorTab 
con t r o 1 Su r f a c e Po s_r ad_a vg E 1 e va torTab 

Average elevator (or 
stabilizer/stabilator) tab control 
surface positions (sum of 
positions/number of surfaces) 

TEU 




5{ Etab 


controlSurf acePos_deg_d i f f E 1 eva torTab 
controlSurf acePos_rad_dif f E 1 eva torTab 

Average differential elevator (or 
stabilizer/stabilator) tab deflection 
(right deflections-left deflections) 

Right control 
TEU 

(RWD moment) 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Sc n 


controlSurf acePos_deg_canard [number of 
canard control surfaces] 

controlSurf acePos_rad_canard [number of 
canard control surfaces] 

Vector of canard control positions, 
one for each surface. Order is 
outboard port (left) to outboard 
starboard. 

TED 


0.0 


Sc 


controlSurf acePos_deg_avgCanard 
controlSurf acePos_rad_avgCanard 

Average canard position (sum of 
positions/number of surfaces) 

TED 


0.0 


Sec 


controlSurf acePos_deg_di f f Canard 
controlSurf acePos_rad_di f f Canard 

Average differential canard 
deflection (LEFT deflections- 
RIGHT deflections) 

LEFT control 
TED 

(RWD moment) 




Sctat> n , 


controlSurf acePos_deg_canardTab [number of 
canard tab control surfaces, number of tabs] 

controlSurf acePos_rad_canardTab [number of 
canard tab control surfaces, number of tabs] 

Array of canard tab positions (i) 
for each surface (n). Order is 
outboard port (left) to outboard 
starboard per control surface. 

TED 




Sctat. 


controlSurf acePos_deg_avgCanardTab 
controlSurf acePos_rad_avgCanardTab 

Average canard tab deflection 
(sum of positions/number of 
surfaces) 

TED 




Sec tab 


controlSurf acePos_deg_dif f CanardTab 
con trolSurfacePos_r ad_d i f f Can a rdTab 

Average differential canard tab 
deflection (LEFT deflections- 
RIGHT deflections) 

LEFT control 
TED 

(R\MD moment) 




Sse 


controlSurf acePos_deg_speedbrake 
controlSurf acePos_rad_speedbrake 

Speedbrake deflection 

Extended 




StGn 


landingGearPosition [number of landing gear 
struts] 

Vector of landing gear positions, 
one for each strut. Order is 
outboard port (left) to outboard 
starboard. 

0= up and 
locked 

1= full extension 
with no weight 
on wheels 


0.0 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



landingGearWeightOnWheels_lbf [number of 
landing gear struts] 

landingGearWeightOnWheels_N [number of 
landing gear struts] 

Vector of landing gear weight on 
wheels, one for each strut. Order 
is outboard port (left) to outboard 
starboard. 







landingGearWheelSpeed_rad_s [number of 
landing gear struts, number of trucks, number 
of wheels per truck] 

Array of landing gear wheel 
speeds by strut, one for each 
strut. Order of struts is outboard 
port (left) strut, to outboard 
starboard. Order of trucks is front 
to rear. Order of wheels on each 
truck is port to starboard 






Table A 8 — Vehicle aerodynamic characteristics 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Q. 

CL 

totalCoeff icientOf Lift 

Coefficient Of Lift, Total, includes 
effects of stores 

UP 




Co 

CD 

total Coef f icientOf Drag 

Coefficient Of Drag, Total, 
includes effects of stores 

AFT 






aeroBodyForceCoef ficient [3] 

Vector of total aerodynamic force coefficients in the body coordinate system, 
comprised of the three components as defined below. 

Cx 

CX 

aeroBodyForceCoef ficient_X 

X-body Force Coefficient due to 
aerodynamic loads, includes 
stores (Body coordinate) 

FWD 




Cy 

CY 

aeroBodyForceCoef f i ci ent_Y 

Y-body Force Coefficient due to 
aerodynamic loads, includes 
stores (Body coordinate) 

RT 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Cz 

CZ 

aeroBodyForceCoef f icient_Z 

Z-body Force Coefficient due to 
aerodynamic loads, includes 
stores (Body coordinate) 

DN 






aeroBodyForce_lbf [3) 
aeroBodyForce_N (3] 

Vector of total aerodynamic forces in the body coordinate system, including 
stores Comprised of the three components as defined below 

Fax 

FAX 

a e r oBody For ce_ 1 bf _X 
ae roBodyForce_N_X 

Total X-body Force due to 
aerodynamic loads, includes 
stores (Body coordinate) 

FWD 




Fay 

FAY 

a e r oBody For ce_ 1 bf _ Y 
aeroBodyForce_N_Y 

Total Y-body Force due to 
aerodynamic loads, includes 
stores (Body coordinate) 

RT 




Faz 

FAZ 

a e r oBody For ce_ 1 bf _Z 
ae roBodyForce_N_Z 

T otal Z-body Force due to 
aerodynamic loads, includes 
stores (Body coordinate) 

DN 






thrustBodyForce_lbf [3] 
thrustBodyForce_N [3] 

Vector of total net propulsion system forces in the body coordinate system 
(includes installation losses, inlet efficiency and propeller efficiency) Comprised 
of the three components as defined below 

Fex 

FEX 

thrustBodyForce_lbf_X 

thrustBodyForce_N_X 

Total net engine thrust Force, X- 
body axis 

FWD 




Fey 

FEY 

thru8tBodyForce_lbf_Y 

thrustBodyForce_N_Y 

Total net engine thrust Force , Y- 
body axis 

RT 




Fez 

FEZ 

thrustBodyForce_lbf_Z 

thrustBodyForce_N_Z 

Total net engine thrust Force, Z- 
body axis 

DN 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 



gearBodyForce_lbf [3] 
gearBodyForce_N [3] 

Vector of total landing gear ground reaction forces in the body coordinate 
system. Does NOT include aerodynamic forces on the landing gear that are 
included in aeroBodyForce defined above. Comprised of the three 
components as defined below. 

Fox 

FGX 

gearBodyForce_lbf_X 
g e a r B ody For c e_N_X 

Total landing gear ground reaction 
force, X-body axis 

FWD 




Fgy 

FGY 

gearBodyForce_lbf_Y 
gearBodyForce_N_ Y 

Total landing gear ground reaction 
force, Y-body axis 

RT 




Fgz 

FGZ 

gearBodyForce_lbf_Z 

gearBodyForce_N_Z 

Total landing gear ground reaction 
force, Z-body axis 

DN 






totalBodyForce_lbf [31 
total BodyForce_N [3] 

Vector of total forces in the body coordinate system. Includes all forces exerted 
upon the aircraft. Comprised of the three components as defined below. 

F„tot 

FX 

totalBodyForce_lbf_X 

totalBodyForce_N_X 

Total Forces On a/c, X-body axis 

FWD 




FyTOT 

FY 

totalBodyForce_lbf_Y 
total Body For c e_N_Y 

Total Forces On a/c, Y-body axis 

RT 




FzTOT 

FZ 

totalBodyForce_lbf_Z 
total Body For c e_N_Z 

Total Forces On a/c, Z-body axis 

DN 






aeroBodyMomentCoef f icient [3] 

Vector of total aerodynamic moment coefficients in the body coordinate system, 
including stores. Comprised of the three components as defined below. 

c, 

CLL 

aeroBodyMomentCoef f icient_Rol 1 

Total Aerodynamic Rolling 
Moment Coefficient including 
stores. Moment about the X-body 
axis 

RWD 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

&, 

CLM 

aeroBodyMomentCoefficient._Pit.ch 

Total Aerodynamic Pitching 
Moment Coefficient, including 
stores. Moment about the Y-body 
axis 

ANU 




G, 

CLN 

aeroBodyMomentCoef f icient_Yaw 

Total Aerodynamic yawing 
Moment Coefficient, including 
stores. Moment about the Z-body 
axis 

ANR 






aeroBodyMoment_f tlbf [3] 
aeroBodyMoment_Nm (31 

Vector of total aerodynamic moments in the body coordinate system, including 
stores Referenced to the moment reference center Comprised of the three 
components as defined below 

La 

TAL 

ae roBodyMomen t_f tlbf _Rol 1 
aeroBodyMoment_Nm_Rol 1 

Total Aerodynamic Rolling 
moment (including attached 
stores), about the X-body axis 

RWD 




Ma 

TAM 

a e roBodyMomen t _£ t 1 bf _Pi t ch 
aeroBodyMomen t_Nm_Pi tch 

Total Aerodynamic pitching 
moment (including attached 
stores), about the Y-body axis 

ANU 




Na 

TAN 

aeroBodyMoment_f t lbf _Yaw 
ae roBodyMomen t_Nm_Y aw 

Total Aerodynamic yawing 
moment (including attached 
stores), about the Z-body axis 

ANR 






thrustBodyMoment_f tlbf [3J 
thrustBodyMoment_Nm [3] 

Vector of total net propulsion system moments in the body coordinate system 
(includes installation losses, inlet efficiency and propeller efficiency) 
Referenced to the moment reference center Comprised of the three 
components as defined below 

Le 

TEL 

thrustBodyMoment_f tlbf_Roll 
thrus tBodyMoment_Nm_Rol 1 

Total Engine Rolling Moment, 
about the X-body axis 

RWD 




Me 

TEM 

thrustBodyMoment_f tlbf _Pi tch 
thrus tBodyMoment_Nm_Pi tch 

Total Engine pitching Moment, 
about the Y-body axis 

ANU 
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Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 

Ne 

TEN 

thrustBodyMoment_f tlbf_Yaw 
thrust BodyMomen t_Nm_Yaw 

Total Engine yawing Moment, 
about the X-body axis 

ANR 






landingGearBodyMoment_f tlbf [3] 
landingGearBodyMoment_Nm 13] 

Vector of total landing gear ground reaction moments in the body coordinate 
system Referenced to the moment reference center Does NOT include 
aerodynamic moments on the landing gear that are included in 
aeroBodyMoment defined above Comprised of the three components as 
defined below 

Lg 

TGL 

landingGear BodyMom en t_f tlbf _Ro 1 1 
1 and i ngGea rBodyMomen t_Nm_Rol 1 

Total Landing Gear Rolling 
Moment, about the X-body axis 

RWD 




Mg 

TGM 

1 and i ngGea rBodyMomen t_f 1 1 bf _P i t ch 
1 andingGearBodyMoment_Nm_Pi tch 

Total Landing gear Pitch Moment, 
about the Y-body axis 

ANU 




No 

TGN 

1 and i ngGea rBodyMomen t_f 1 1 bf _Y aw 
1 and i ngGea rBodyMomen t_Nm_Y aw 

Total Landing Gear Yawing 
Moment, about the Z-body axis 

ANR 






totalBodyMoment_f tlbf [3] 
total BodyMoment_Nm [3] 

Vector of total moments in the body coordinate system Referenced to the 
moment reference center Includes all moments exerted upon the aircraft 
Comprised of the three components as defined below 

Ltot 

TTL 

totalBodyMoment_f tlbf_Roll 
tota 1 BodyMomen t_Nm_Ro 1 1 

Total Rolling Moment, about the 
X-body axis 

RWD 




Mtot 

TTM 

tota 1 BodyMomen t_f 1 1 bf _Pi tch 
totalBodyMoment_Nm_Pltch 

Total Pitching Moment, about the 
Y-body axis 

ANU 




Ntot 

TTN 

total BodyMomen t_f 1 1 bf _Yaw 
total BodyMomen t_Nm_Y aw 

Total Yawing Moment, about the 
Z-body axis 

ANR 
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Table A.9 — Simulation control parameters 


Symbol 

Short 

Name 

Full Variable Name 

Description 

Positive Sign 
Convention 

Initial 

Value 

Min 

Value 

Max 

Value 


TIME 

simDuracion_s 

Time Since Start Of Operate 
Mode 

NSC 






deltaTime_s [number of different integration 
step sizes] 

Vector of Integration step sizes 







simDate 

Date simulated. Date at the start 
of the simulation is used. (Not the 
date the simulation run was made) 

T ype yyyy-mm-dd 







simTime 

Simulated time of day based on 
24 hours Zulu. 





Type hh:mm:ss.ss 



product ionDate 

Date the simulation run was made 
(Not the simulated date [simDate]) 

T ype yyyy-mm-dd 
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References 


GRAM 07. 

Justus, C.G.; and Leslie, F. W. : "The NASA MSFC Earth Global Reference 
Atmospheric Model— 2007 Version" NASA TM-2008-21558 1 

For symbols: 

ISO 1151-1 : 1988 
ISO 1151-2 : 1985 
ISO 1151-4 : 1994(E) 

ISO 1151-5 : 1987 

Not all symbols presented above are defined by ISO. This document attempts to make them 
consistent where similar. 


For Time and Dates: 

ISO 8601 :2000 
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DAVE-ML Website (Informative) 

The “official" DAVE-ML site is http://davcml.ore/' . This link contains all DAVE-ML 
documentation and links and information on DAVE-ML tools and applications. Additional 
information is available at http://www.aiaa- ora/ 
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Appendix C. XML Document Type Definition file for 
S-119 markup: DAVEfunc . dtd 

<?xml vers1on="l. 0” encoding= "UTF-8 "?><! — 

Dynamic Aerospace Vehicle Exchange DTD 
Function Data Representation 

Version: 2.0 Release candidate 3 


This dtd module is identified by these PUBLIC and SYSTEM 
identifiers: 

public "-//aiaa//dtd for Flight Dynamic Models - Functions 2.0//EN" 
system "http : //daveml . org/DTDs/2pORC3/DAVEf unc . dtd" 

Developed by: 

American Institute of Aeronautics and Astronautics (AIAA) 

Modeling & Simulation Technical Committee 
Simulation Modeling Standards Subcommittee 

Contact information: 

E. Bruce iackson <mailto:bruce.jackson@nasa.gov> 

Bruce L. Hildreth <mailto:bhildreth@jfti.com> 
persistent DAVE-ML contact <mailto:info@daveml.org> 

<http: //daveml .org> 

purpose: 

Proposed standard for exchanging dynamic models of aerospace 
vehicles, including aero, engine, gear, inertia, and control 
model s. 

This preliminary version defines static models typically 
associated with aerodynamic subsystem models, but can be used to 
describe any non-linear multi -dimensional function. 

Status: 

In development. Direct comments to above contacts. 


<! — 


— > 


Ac knowl edgments : 

The editors would like to acknowledge the contributions, 
encouragement and helpful suggestions from Dennis Linse 
(originally SAIC, now Vuelo Software Analysis), Ion Berndt (Jacobs 
Sverdrup), Brent York (Indra), Bill Cleveland (NASA Ames) , Geoff 
Brian (Australia's DSTO) , 3. Dana McMinn (NASA Langley), Peter 
Grant (UTIAS) , Giovanni A. Cignoni (University of Pisa), Daniel 
M. Newman (formerly Ball Aerospace, now Quantitative Aeronautics), 
Hilary Keating (Fortburn Pty. Ltd.), Riley Rainey (sds 
I nternational), Jeremy Furtek (Delphi Research) and Randy 
Brumbaugh (Indigo Innovations). 
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Include the MathML2 DTD for any math markup 


--> 


<! ENTITY % mathml 2 PUBLIC "-//W3C//DTD MathML 2 . 0//EN" 

"http://www.w3.org/Math/DTD/mathml 2/mathml2 . dtd"> 
%mathm!2; 


<! — +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ — > 
<! — Level 0 Elements — > 

<! — +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ — > 

< ! - - ======================================= 


Root element is DAVEfunc, composed of a file header element 
followed by one or more variable definitions and zero or more 
breakpoint definitions, gridded or ungridded table definitions, 
and function elements. 




<! ELEMENT DAVEfunc ( 
fileHeader , 
variableDef+, 
breakpointDef*, 
griddedTableDef* , 
ungri ddedTabl eDef* , 
function*, 
checkData? 


<!ATTLIST DAVEfunc 

xml ns CDATA # FIXED 


' http : //daveml .org/2010/DAVEML' 


<! -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ — > 
<! — Level 1 Elements — > 

<! -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> 

<! — ============================================= 


The header element requires at least one author and a creation date; 
optional content includes version indicator, description, 
references, and modification records. 


<! ELEMENT fileHeader ( 
author+, 

(creationDate | fileCreationDate) , 

fil eversion?, 

description?, 

reference*, 

modificationRecord* , 

provenance* 


< ! ATTLIST fileHeader 

name CDATA #IMPLIED 
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<!- 


variableDef elements provide wiring information (i.e., they 
identify the input and output signals used by these function 
blocks). They also provide MathML content markup to indicate any 
calculation required to arrive at the value of the variable, 
using other variables as inputs. The variable definition can 
include statistical information regarding the uncertainty of the 
values which it might take on, when measured after any 
calculation is performed. Information about the reason for 
inclusion or change to this element can be included in an 
optional provenance sub-element. 


--> 


<! ELEMENT variableDef ( 
description?, 

(provenance | provenanceRef)? , 
calculation?, 

(islnput | isControl | 
i sState?, 
isStateDeriv?, 
i sOutput?, 
i sStdAIAA? , 
uncertainty? 


) 

> 

<! attlist variableDef 


name 

CDATA 

varlD 

ID 

units 

CDATA 

axisSystem CDATA 

sign 

CDATA 

alias 

CDATA 

symbol 

CDATA 

i niti alValue 


isDisturbance)?, 


#REQUIRED 

#REQUIRED 

#REQUIRED 

#IMPLIED 

#IMPLIED 

#IMPLIED 

#IMPLIED 

CDATA #IMPLIED 


<! ELEMENT variableRef EMPTY> 

< ! ATTLIST variableRef 

varlD IDREF #REQUIRED 

> 


A breakpoi ntDef lists gridded table breakpoints. 

Since these are separate from function data they may be reused. 


<! ELEMENT breakpoi ntDef ( 
description?, 
bpVal s 


<! ATTLIST breakpointDef 

name CDATA #IMPLIED 

bpID ID #REQUIRED 

units CDATA #IMPLIED 
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<!-- = 


bpVals is a set of breakpoints (i.e., a set of independent 
variable values associated with one dimension of a gridded table 
of data). An example would be the Mach or angle-of- attack values 
that define the coordinates of each data point in a 
2D coefficient value table. 


— > 


<! ELEMENT bpVals (#PCDATA)> 


A griddedTableDef contains points arranged in an orthogonal (but 
multi-dimensional) array, where the independent variables are 
defined by separate breakpoint vectors. This table definition 
may be specified separately from the actual function 
declaration; if so, it requires a gtlD identifier attribute so 
that it may be used by multiple functions. 




<! ELEMENT griddedTableDef ( 
description?, 

(provenance | provenanceRef)? , 

breakpointRefs, 

uncertainty?, 

dataTable 


< ! ATTLIST griddedTableDef 

name CDATA #IMPLIED 
gtlD ID #IMPLIED 
units CDATA #IMPLIED 


An ungriddedTableDef contains points that are not in an 
orthogonal grid pattern; thus, the independent variable 
coordinates are specified for each dependent variable value. 

This table definition may be specified separately from the 
actual function declaration; if so, it requires an internal utlD 
identifier attribute so that it may be used by multiple 
functions. 


> 


<! ELEMENT ungriddedTableDef ( 
description?, 

(provenance | provenanceRef)?, 

uncertainty?, 

dataPoint+ 


<! ATTLIST ungriddedTableDef 

name CDATA #IMPLIED 
UtID ID #IMPLIED 
units CDATA #IMPLIED 
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<!-- = 


Each function has optional description, optional provenance, and 
either a simple input/output table values or references to more 
complete (possible multiple) input, output, and function data 
elements. 


<! ELEMENT function ( 
description?, 

(provenance | provenanceRef)?, 

i ndependentVar Pts+ , 
dependentVarPts 

i nciependentVarRef+ , 
dependentVarRef , 
functionDefn 

)) 


< ! ATTLIST function 

name cdata #required 


This top-level element is the place-holder for verification data 
of various forms for the encoded model. It will include static 
check cases, trim shots, and dynamic check case information. 

The provenance sub-element is now deprecated and has been moved 
to individual staticShots; it is allowed here for backwards 
compatibility. 


> 


<! ELEMENT checkData ( 

(provenance | provenanceRef)?, 
staticshot+ 


<! — +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ — > 
<!-- Level 2 Elements — > 


-i 


author includes alternate means of identifying author using XNS 
or normal e-mail/address. The address sub-element is to be 
replaced with the more complete contactlnfo sub-element. 


<! ELEMENT author (address* | contactlnfo*)> 
<! ATTLIST author 


name 

org 

xns 

email 


CDATA #REQUIRED 
CDATA #REQUIRED 
CDATA #IMPLIED 
CDATA #IMPLIED 
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> 

<!-- = 


creationDate is simply a string with a date in it. We 
follow ISO 8601 and use dates like "2004-01-02" to refer to 
January 2, 2004. 


< ! ELEMENT creationDate EMPTY> 

< ! ATTLIST creationDate 

date CDATA #REQUIRED 

> 

< ! - - == ===== === 


fileCreationDate is simply a string with a date in it. we 
follow ISO 8601 and use dates like "2004-01-02" to refer to 
January 2, 2004. Its use is now deprecated in favor of the 
simpler creationDate. 


<! ELEMENT fileCreationDate EMPTY> 
<! ATTLIST fileCreationDate 

date CDATA #REQUIRED 

> 


This is a string describing, in some arbitrary text, the version 
identifier for this function description. 


<! ELEMENT fileVersion (#PCDATA)> 


<!-- = 


The description element is a textual description of an 
entity. The full UNICODE character set is supported by XML but 
may not be available in all processing applications. 


— > 


<! ELEMENT description (#PCDATA)> 


<! — 


The presence of the isOutput element indicates that this 
variable should be forced to be an output, even if it is used 
internally as an input elsewhere, otherwise, the processing 
program may assume a signal defined with a calculation and used 
subsequently in the model is only an internal signal. 


> 


<! ELEMENT iSOUtpUt EMPTY> 
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<!-- = 


The presence of an isState element indicates that this variable 
is one of possibly multiple state variables in a dynamic model; 
this tells the processing entity that this is the output of an 
integrator (for continuous models) or a discretely updated state 
(for discrete models). 


--> 


<! ELEMENT isState EMPTY> 


<! — == 


The presence of an isStateDeriv element indicates that this 
variable is one of possibly several state derivative variables 
in a dynamic model; this tells the processing entity that this 
is the output of an integrator (for continuous models only). 


<! ELEMENT isStateDeriv EMPTY> 


<!-- === 


The presence of an islnput element indicates that this variable 
is an input signal to the model. 


<! ELEMENT 1 Slnput EMPTY> 


<! 


The presence of an isControl element indicates that this signal 
is a simulation control parameter used to vary the operation of 
the model, e.g. the time step size, such parameters should be 
ignored when performing linear model extraction (for example) 
and should not significantly modify the dynamic behavior of the 
model . 


<! ELEMENT isControl EMPTY> 


The presence of an i sDi sturbance element indicates that this 
signal is an external disturbance input to the model and can be 
ignored when performing linear model extraction (for 
example). Such parameters should not significantly modify the 
nominal dynamic behavior of the model. 


<! ELEMENT i sDi sturbance EMPTY> 
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The presence of an isStdAlAA element indicates that this 

variable is one of the standard AIAA variable names 

which should be recognizable exterior to this module 

(e.g. AngleOfAttack_deg) . This flag should assist importing tools in 

determining when an input or output should match a 

facility-provided signal name without requiring further 

information. 


<! ELEMENT i sStdAIAA EMPTY> 


<! 


The calculation element is MathML 2 content markup describing 
how the signal is calculated. The calculation may include both 
constants and variables; other variables are included by using 
their varlD string in a MathML content identifier (ci) element. 


— > 


<! ELEMENT calculation (math)> 




This element gives identifying (citation) information to an 
external, possibly on-line, reference document, including a 
user-specified author, title, classification, accession number, 
date and URL. 


— > 


< ! ELEMENT reference (description?)> 
< ! ATTLIST reference 


xmlns:xlink 
xlink:type (simpl 
refID ID 

author CDATA 
title CDATA 

classification 
accession CDATA 
date CDATA 

xl ink: href CDATA 


CDATA #FIXED 
) #FIXED 

#REQUIRED 
#REQUIRED 
#REQUIRED 
CDATA #IMPLIED 
#IMPLIED 
#REQUIRED 
#IMPLIED 


' http://www.w3.org/1999/xlink' 
' simple' 


> 


< ! — 


A modifi cationRecord associates a single letter (such as 
modification "A") with modification author(s), address, and any 
optional external reference documents, in keeping with the AIAA 
draft standard. 


< ! ELEMENT modi fi cat i onRecord ( 
author+ , 
description?, 
extraDocRef* 


Page 8 


NESC Request No.: 09-00598 


© 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

191 of 
343 


< ! ATTLIST modi ficationRecord 

modID ID #REQUIRED 

date CDATA #REQUIRED 

ref ID IDREF #IMPLIED 

> 


A single modification event may have more than one documented 
reference. This element can be used in place of the ref ID 
attribute in a modi ficationRecord to record more than one 
reflDs, pointing to the referenced document. 


<! ELEMENT extraDocRef EMPTY> 

<! ATTLIST extraDocRef 

refID IDREF #REQUIRED 

> 

< ! - - ================== 


The provenance element describes the history or source of the 
model data and includes author, date, and zero or more 
references to documents and modification records. 


<! ELEMENT provenance ( 
author+, 

(creationDate | functionCreationDate) , 
document Ref* , 
modi f i cati onRef* , 
description? 


<! ATTLIST provenance 

provID ID #IMPLIED 




When the provenance of a set of several data is identical, the 
first provenance element should be given a provID and referenced by 
later provenanceRef elements. 


<! ELEMENT provenanceRef EMPTY> 

<! ATTLIST provenanceRef 

provID IDREF #REQUIRED 

> 


An independentVarPts element is a simple white space- or 
comma-separated list of breakpoints and contains a mandatory 
varlD identifier as well as optional name, units, and sign 
convention attributes. 

An optional extrapolate attribute describes how to extrapolate 
the output value when the input value exceeds specified values 
(default is 'neither,' meaning the value of the table is held 
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constant at the nearest defined value). An optional interpolate 
attribute indicates how to perform the interpolation within the 
table (supporting discrete, linear, cubic or quadratic 
splines). There are three different discrete options: ’discrete' 
means nearest-neighbor, with an exact mid-point value being 
rounded in the positive direction; ’ceiling’ means the function 
takes on the value associated with the next (numerically) higher 
independent breakpoint as soon as the original value is exceeded; 
and 'floor* means the function holds the value associated with 
each breakpoint until the next (numerically) higher breakpoint 
value is reached by the independent argument. Tne default 
interpolation attribute value is 'linear.' 

This element is used for simple functions that do not share 
breakpoint or table values with other functions. 




<! ELEMENT i ndependentVarPts (#PCDATA)> 
< ! ATTLIST i ndependentVarPts 

varlD IDREF #REQUIRED 

name CDATA 

units CDATA 

sign CDATA 

extrapolate 
interpolate 
cubicSpl ine) ^IMPLIED 
> 


#IMPLIED 
#IMPLIED 
#IMPLIED 

(neither | min | max | both) #IMPLIED 

(discrete | floor | ceiling | linear | quadraticSpline 


< ! 


i — 


A dependentVarPts element is a simple comma- or 
white space-delimited list of function values and contains a 
mandatory varlD as well as optional name, units, and sign 
convention attributes. Data points are arranged as single 
vector with last-specified breakpoint values changing most 
frequently. Note that the number of dependent values must equal 
the product of the number of independent values for this simple, 
gridded, realization. This element is used for simple functions 
that do not share breakpoint or table values with other 
functions. 


— > 


<! ELEMENT dependentVarPts (#PCDATA)> 
<! ATTLIST dependentVarPts 

varlD IDREF #REQUIRED 

name CDATA #IMPLIED 

units CDATA #IMPLIED 

si gn CDATA #IMPLIED 


<! — 


An independentVarRef more fully describes the input mapping of 
the function by pointing to a separate breakpoint definition 
element. 

An optional extrapolate attribute describes how to extrapolate 
the output value when the input value exceeds specified values 
(default is 'neither,' meaning the value of the table is held 
constant at the nearest defined value). An optional interpolate 
attribute indicates how to perform the interpolation within the 
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table (supporting discrete, linear, cubic or quadratic 
splines). There are three different discrete options: 'discrete' 
means nearest-neighbor, with an exact mid-point value being 
rounded in the positive direction; 'floor' means the function 
takes on the value associated with the next (numerically) higher 
independent breakpoint as soon as original value is exceeded; 
and 'ceiling' means the function holds the value associated with 
each breakpoint until the next (numerically) higher breakpoint 
value is reached by the independent argument. The default 
interpolation attribute value is 'linear.' 

This element allows reuse of common breakpoint values for many 
tables but with possible differences in interpolation or 
extrapolation for each use. 


<! ELEMENT i ndependentVarRef EMPTY> 
clATTLIST i ndependentVarRef 

varlD IDREF #REQUIRED 

min CDATA #IMPLIED 

max CDATA #IMPLIED 

extrapolate (neither | 

interpolate (discrete 

cubicSpline) #IMPLIED 
> 


min | max | both) #IMPLIED 
| floor | ceiling | linear | 


quadraticspline 


<! — 


A dependentVarRef ties the output of a function to a signal name 
defined previously in a variable definition. 




<! ELEMENT dependentVarRef EMPTY> 
clATTLIST dependentVarRef 

varlD IDREF #REQUIRED 

> 


A functionDefn defines how function is represented in one of two 
possible ways: gridded (implies breakpoints) or ungridded (with 
explicit independent values for each point). 


< ! ELEMENT functionDefn (griddedTableRef | griddedTableDef | griddedTable | 
ungriddedTableRef | ungri ddedTabl eDef | ungriddedTable)> 
clATTLIST functionDefn 

name CDATA #IMPLIED 

> 


cl — 


c! - 
c! - 


Level 3 Elements 



c I ELEMENT address (#PCDATA)> 


cl- 
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Used to provide contact information about an author. Use 
contactlnfoType to differentiate what information is being 
conveyed and contactLocation to denote location of the address. 


— > 


<! ELEMENT contactlnfo (#PCDATA)> 

<! ATTLIST contactlnfo 

contactlnfoType (address | phone | fax | email | iname | web) #IMPLIED 
contactLocation (professional | personal | mobile) #IMPLIED 


<! — ==: 


functionCreationDate is simply a string with a date in it. We 
follow ISO 8601 and use dates like "2004-01-02" to refer to 
January 2, 2004. Its use is now deprecated in favor of the 
simpler creationDate. 




< ! ELEMENT functionCreationDate EMPTY> 

< ! ATTLIST functionCreationDate 

date CDATA #REQUIRED 

> 

<! ELEMENT documentRef EMPTY> 

<! ATTLIST documentRef 

docID IDREF #IMPLIED 

refID IDREF #REQUIRED 

> 

<! ELEMENT modi f i cati onRef EMPTY> 

<! ATTLIST modi fi cati onRef 

modlD IDREF #REQUIRED 

> 

< ! ELEMENT gri ddedTabl eRef EMPTY> 

<! ATTLIST gri ddedTabl eRef 

gtID IDREF #REQUIRED 

> 

< ! ELEMENT griddedTable ( 
breakpointRefs, 
conf i denceBound? , 
dataTabl e 

) 

> 

< (ATTLIST griddedTable 

name CDATA #IMPLIED 

> 

< ! ELEMENT ungri ddedTabl eRef EMPTY> 

< (ATTLIST ungriddedTableRef 

UtID IDREF #REQUIRED 

> 

< ! ELEMENT ungri ddedTabl e ( 
confi denceBound?, 
dataPoint+ 

) 

> 

< (ATTLIST ungri ddedTabl e 
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name CDATA #IMPLIED 

> 


val ues 


Contains a description of the inputs and outputs, and possibly internal 
, of a DAVE-ML 

model in a particular instant of time. 


— > 


<! ELEMENT staticShot ( 
description?, 

(provenance | provenanceRef)?, 
checklnputs, 
internal Val ues?, 
checkoutputs 

> 

< ! ATTLIST staticShot 

name CDATA #REQUIRED 

refID IDREF #IMPLIED 

> 


"V ; T — r it i fill i — I — I — I — r T I — rTTTTTTTl — I T I T — I I I — — r T I — r I 1 — r i i ■ ■ i I — I I I — r T I — TTT — TTT — r I i — r i ^ 

<! — Level 4 Elements — > 

<! — +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ — > 


The breakpointRefs elements tie the independent variable names 
for the function to specific breakpoint values defined earlier. 


— > 


<! ELEMENT breakpointRefs (bpRef+)> 


<!-- 


The confidenceBound element is used to declare the confidence 
interval associated with the data table. This is a place-holder 
and will be removed in a future version of DAVE-ML. 


--> 


<! ELEMENT confidenceBound EMPTY> 
<! ATTLIST confidenceBound 

value CDATA #REQUIRED 

> 

< ! - 


[ he uncertainty element is used in function and parameter 
definitions to describe statistical variance in the possible 
value of that function or parameter value. Only Gaussian 
fnormal) or uniform distributions of continuous random variable 
distribution functions are supported. 


<! ELEMENT uncertainty (normal PDF | uniformPDF)> 
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< ! ATTLIST uncertainty 

effect (additive | multiplicative | percentage | absolute) #REQUIRED 

> 


The dataTable element is used by gridded tables where the indep. 
variable values are implied by breakpoint sets. Thus, the data 
embedded between the dataTable element tags is expected to be 
sorted ASCII values of the gridded table, wherein the last 
independent variable listed in the function header varies most 
rapidly. 

The table data point values are specified as comma- or 
white space-separated values in conventional floating-point 
notation (0. 93638E-06) in a single long sequence as if the table 
had been unraveled with the last-specified dimension changing 
most rapidly. Line breaks are to be ignored. Comments may be 
embedded in the table to promote [human] readability, with 
appropriate escaping characters. 

A dataTable element can also be used in an uncertainty element 
to provide duplicate uncertainty bound values. 


== — > 


<! ELEMENT dataTable (#PCDATA)> 
< ! — ================== 


The dataPoint element is used by ungridded tables to list the 
values of independent variables that are associated with each 
value of dependent variable. For example: 

<dataPoint> 

0.1, -4.0, 0.2 <!- Mach, alpha, CL -> 

</dataPoint> 

<dataPoint> 

0.1, 0.0, 0.6 <!- Mach, alpha CL -> 

</dataPoint> 

Each data point may have associated with it a modification tag 
to document the genesis of that particular point. No 
requirement on ordering of independent variables is implied. 

Since this is an ungridded table, the interpreting application is 
required to handle what may be unsorted data. 


— > 


<! ELEMENT dataPoint (#PCDATA)> 

<! ATTLIST dataPoint 

modlD IDREF #IMPLIED 

> 

Specifies the contents of the input vector for the given check case. 
<! ELEMENT checklnputs (signal+)> 
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Provides a set of all internal variable values to assist in debugging 
recalcitrant 

implementations of DAVE-ML import tools. 


<! ELEMENT i nternalValues (signal+)> 


<!-- == 


specifies the contents of the output vector for the given check 
case . 


<! ELEMENT checkoutputs (signal+)> 


<! — 
<! — 
<! -- 


Level 5 Elements 


— > 




<!-- 


The bpRef element provides references to a previously-defined 
breakpoint set so breakpoints can be defined separately from, 
and reused by, several data tables. 


<! ELEMENT bpRef EMPTY> 

< ! ATTLIST bpRef 

bpID IDREF #REQUIRED 

> 


In a normally distributed random variable, a symmetrical 
distribution of given standard deviation is assumed about the 
nominal value (which is given elsewhere in the parent element). 

The correlateswith sub-element references other functions or 
variables that have a linear correlation to the current 
parameter or function. The correlation sub-element specifies the 
correlation coefficient and references the other function or 
variable whose random value helps determine the value of this 
parameter. 


<! ELEMENT normal PDF ( 
bounds, 

correlateswith*, 

correlation* 

) 

> 

<! ATTLIST normal PDF 

numSigmas CDATA #REQUIRED 

> 
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cl- 


ln a uniformly distributed random variable, the value of the 
parameter has equal likelihood of assuming any value within the 
(possibly asymmetric, implied by specifying two) bounds, which 
must bracket the nominal value (which is given elsewhere in the 
parent element). 


— > 


<! ELEMENT uniformPDF (bounds+)> 




This element contains some description of the statistical limits 
to the values the citing parameter element might take on. This 
can be in the form of a scalar value, a private dataTable, or a 
variableRef. In the more common instance, this element will 
either be a scalar constant value or a simple table whose 
dimensions must match the parent nominal function table and 
whose independent variables are identical to the nominal 
table. It is also possible that this limit be determined by an 
independent variable, either previously defined or defined 
in-line with this element. It does not make sense to have a 
dataTable cited if this bounds element is associated with 
anything other than an identically shaped function table. 


— > 


<! ELEMENT bounds (#PCDATA | dataTable | variableDef | variableRef)*> 


<! 


When present, this element indicates the parent function or 
variable is correlated with the referenced other function or 
variable in a linear sense. This alerts the application that 
the random number used to calculate this function's or variable's 
immediate value will be used to calculate another function's or 
variable’s value. 


<! ELEMENT cor rel atesWi th EMPTY> 

< ! ATTLIST cor rel atesWi th 

varlD IDREF #REQUIRED 

> 

< ! — ======== ==== 


When present, this element indicates the parent function or 
variable is correlated with the referenced other function or 
variable in a linear sense and gives the correlation 
coefficient for determining this function's random value based 
upon the correlating function(s) ' s random value. 


> 


<! ELEMENT correlation EMPTY> 

<! ATTLIST correlation 

varlD IDREF #REQUIRED 

Page 16 


NESC Request No.: 09-00598 


© 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

199 of 
343 


correoef CDATA #REQUIRED 

> 


This element is used to document the name, ID, value, tolerance, 
and units of measure for check-cases. When used with checklnputs 
or checkOutputs, the signal Name sub-element must be present 
(since check cases are viewed from "outside" the model); when 
used in an internalValues element, the varlD sub-element should 
be used to identify the signal by its model -unique internal 
reference. When used in a checkOutputs vector, the tol element 
must be present. Tolerance is specified as a maximum absolute 
difference between the expected and actual value. 

The signallD sub-element is now deprecated in favor of the more 
consistent varlD. 


> 


<! ELEMENT signal ( 

(( . . 

signal Name, 

signal Units 

) I ( 

(varlD | signallD) 

)), 


signalValue, 

tol? 


) 


> 


N : ~~T~TT T T i i T T i i TTTTT i T i TT i TTT~TT TTTTTT I TT T I T T T T T ~T T T I I T • n — 11 I ll I II T 

<! — Level 6 Elements — > 

< ! — +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ — > 

<! — ============================================= 


Used inside a checkCase element to specify the input or output 
variable name 


— > 


<! ELEMENT signal Name (#PCDATA)> 


<!-- 


Used to specify the input or output varlD. Now deprecated; reuse 
of varlD is best practice. 


<! ELEMENT signallD (#PCDATA)> 


Used to specify the input or output varlD. Replaces earlier 
signallD element. 
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<! ELEMENT varlD (#PCDATA)> 


Used inside a checkcase element to specify the units-of -measure 
for an input or output variable, for verification of proper 
implementation of a model. 


--> 


c'element signalunits (#pcdata)> 




Used to give the current value of an internal signal or 
input/output variable, for verification of proper implementation 
of a model . 


> 


<!element signalvalue (#pcdata)> 


This element specifies the allowable tolerance of error in an 
output value such that the model can be considered verified. It 
is assumed all uncertainty is removed in performing the model 
calculations. Tolerance is specified as a maximum absolute 
difference between the expected and actual value. 


================================================= - -> 

<! ELEMENT tol (#PCDATA)> 
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Appendix D. Dynamic Aerospace Vehicle Exchange Markup 
Language (DAVE-ML) Reference Manual 


Dynamic Aerospace Vehicle 
Exchange Markup Language 
(DAVE-ML) Reference 

Version 2.0 (Release Candidate 3) 

2010-05-07 


AIAA Modeling and Simulation Technical 
Committee [https://info.aiaa.org/tac/ASG/MSTC] 


E. Bruce Jackson, NASA Langley Research Center <bruce. jackson®nasa.gov> 


Abstract 

The Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) 
is a text-based file format intended for encoding the principal elements 
of a flight simulation model for an aerospace vehicle. It is based on two 
other open standards: the Extensible Markup Language (XML) version 
1.1 and the Mathematical Markup Language (MathML) version 2.0, both 
products of the World Wide Web Consortium. DAVE-ML defines additional 
grammar (markup elements) to provide a domain-specific language capable 
of aerospace flight dynamics modeling, verification, and documentation. 

This markup language represents the encoding format for BSR/AIAA S-1 19 
Flight Dynamic Model Exchange Standard [AIAA10], 

This is a draft version of the reference manual for DAVE-ML syntax and 
markup. DAVE-ML syntax is specified by the DAVEfunc.dtd Document 
Type Definition (DTD) file; the version number above refers to the version 
Of the DAVEfunc . dtd. 

DAVE-ML is an open standard, being developed by an informal team 
of American Institute of Aeronautics and Astronautics (AIAA) members. 
Contact the author above for more information or comments regarding 
refinement of DAVE-ML. 
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DAVE-ML 2 
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DAVE-ML 2 


1. Changes to this document 

This section contains a list of changes during the development of the DAVE-ML DTD. 

1.1. Changes since version 2.0RC2 

This section outlines changes to the DTD and this reference manual since version 2, release 

candidate Z was released in October 2008. 

The changes are divided into structural changes to the DTD and non-stmclural changes to the 

DTD and reference manual. 

1.1.1. DTD structural changes since version 2.0RC2 

• Connected the DTD to require at least one staticShot child element of the checkData 
element. 

• Changed tire DTD logic for inclusion of provenance information for elements 
griddedTableDef. ungriddedTableDef. function. checkData. and 
staticShot from 


( provenance? | provenanceRef ? ) 


to 


( provenance | provenanceRef )? 

which is the more correct w ay to display an optional selection from two choices. However, 
use of provenance or provenanceRef is now deprecated for checkData elements as 
described in the non-struetural changes below; this change was made for consistency with the 
other elements that have provenance information. 

• Added optional, mutually exclusive flag elements islnput, isControl. and 
isDisturbance to conform with the latest draft of [AIAA10J. These flags arc intended 
to help clarify the role of all defined variables and to assist in analyses such as linear model 
extraction. 

• Changed the Uniform Resource Identifier (URI) for the atun2 function definition to the 
daveml.org domain. 

• Changed SYSTEM ID to reflect new daveml.org domain; changed PUBLIC ID from NASA 
to AIAA. 

• In tlie DID, the default DAVE-ML namespace definition was added to the top-level 
DAVEfunc element to observe a best-practice for XML DTDs, at the suggestion of Dan 
Newman. 

• In the DTD and reference manual, changed the bpVals elements to allow white space 
separation of values in addition to comma separation (which has always been the case for the 
dataTable element). Ditto for dependentVarPts and independentVarPts. This 
may cause a problem for some existing parsers. 


4 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

205 of 
343 


DAVE-ML 2 


No other changes have been made to the DAVE-ML grammar since 2.0RC2, but this version of 

the DTD and reference manual include clean-up of a number of inconsistencies (found by Dennis 

Linsc and Trey Arthur) between the reference manual and element descriptions, as noted below. 

1.1.2. Non-structural DTD and reference manual changes since version 2.0RC2 

• Corrected second ungridded table definition example and CLRUDO function example; 
reformatted page references from [xx] to (p. xx) in the PDF reference manual, thanks to 
suggestions by Dennis Linse. 

• Amplified and elaborated on possible values for interpolate and extrapolate 
attributes for independent variables of function definitions. 

• Added an index to the reference manual. 

• Removed the sign convention list as this is now in the overlying AIAA draft standard. S-l 19 
[AIAA10], 

• Added clarification that, while uncertainty can be applied in multiple places in the model 
(including input, calculations, functions, and outputs), it is probably not a good practice to 
do so. 

• Changed the non-dimensional signal units-of-measure indication from blank or ND to 'nd‘, 
in accordance with the latest draft standard [AIAA10J; removed plus sign from front of sign 
convention since it doesn't always apply and is redundant to the definition. 

• Added references to earlier standards papers by B. Hildreth [Hildrcth94], [Hildreth98], 

• Cleaned up formatting in the element descriptions found in Section 8.2 (p. 62) corrected 
the grammar in the BNF descriptions of the ma jor elements within this text. 

• Added two sentences to the description of the calculation element, explaining how to tic 
variables in the model to the MathML expression via tire MathML content identifier (ci) 
element. Thanks to Missy Hill and Curtis Zimmerman for pointing out the lack of explanation. 

• Changed email address forB. Hildreth; added persistent email at daveml.org; changed default 
Uniform Resource Locator (URL) to daveml.org 

• Changed the description of bounds clement in the DTD to remove out-of-date reference to 
[un]griddcdTable[Def]Ref| since this is no longer supported. In the reference manual, removed 
a misleading second bounds element for the uniformPDF element case and added notes to 
imply tlie presence of PCDATA (either one or two, depending on the ease). Thanks to Dan 
Newman for prompting this review and change. 

• Did more DTD clean-up to remove redundant 'optional' specifiers on elements and attributes; 
made the 'internal identifier' descriptions consistent throughout the DTD and reference 
manual; tweaked the style of the reference pages in the reference manual; fixed poor grammar 
in the DTD; replaced parentheses with brackets in the BNF syntax in the reference manual for 
comments to avoid confusion; reformatted the reference pages in the manual for readability; 
and added references to W3C on-line documentation where necessary. Thanks to Dennis Linse 
for encouraging the correction of these long-standing inconsistencies and distractions. 
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• Put editorial comments in BNF syntaxes in braces ({}) to avoid confusion with parentheses, 
which are used to indicate a choice. Thanks to Dennis Linse for the catch. 

• In the DTD, a sentence was added to the description of the deprecated f ileCreationDate 
element and a similar description was added to the deprecated functionCreationDate 
element mentioning that both of them have been deprecated in version 2.0. The clarification 
was made after near-simultaneous suggestions from both Trey Arthur and Dan New man. 

• Added a paragraph about the alias attribute of the variableDef element; it's a valid 
attribute but w as missing an explanation. Thanks to Trey Arthur for catching this long-standing 
omission. 

• Changed the definition of alan2 so that the input arguments are not limited to ± 1 and are not 
referred to as 'sine' and 'cosine' to belter match .ANSI C. 'Blanks to Dan New man for catching 
this inconsistency. 

• Corrected typographical errors in f ileHeacler, variableDef, griddedTableDef, 
ungriddedTableDef , and function clement schematic overview syntaxes in sections 
6.2.1 -6.2.6. Thanks to Dennis Linse for catching these errors. 

• Added a sentence about the tol sub-element being an absolute difference to remove 
ambiguity over its interpretation. 

• In the reference manual syntax layout, moved the provenance and provenanceRef 
sub-elements out of checkData and into staticShot sub-elements since checkData, 
a singleton place-holder, doesn't warrant a description but each staticShot docs, 
provenance and provenanceRef arc still in the DTD for checkData but only for 
backwards compatibility; their use in a checkData clement is deprecated and may be 
removed in a future version. Thanks to Dennis Linse for prompting this needed change. 

• Added a note to documentRef docID attribute that it is deprecated. Thanks to Dennis Linse 
for catching this omission. 

• Removed the redundant "optional" in the description of reference element's 
xlink : href attribute. Added the constant value for attributes xmlns : xlink and 
xlinlc : type. Expanded the somewhat terse description of this clement. Thanks to Dennis 
Linse for this correction and other helpful suggestions. 

1.2. Changes since version 2.0RC1 

• Tw eaked examples and syntaxes to match the 2.0 RC 2 DTD. Cleaned up a couple of figures 
and incorporated several new reference citations. Added interpolation paragraph. 

• Deprecated signallD used for internal signals in check-case data in favor of the more 
consistent varlD (which meant the introduction of a formal varlD element) and made 
the specification of signalUnits sub-element mandatory for input and output signals for 
consistency. Thanks to Dan Newman for helping solidify' the thinking about this issue. 

• Changed examples in this text to use updated AIAA variable names to match a revised (but 
unpublished) draft standard of September 2008. Changed many 'examples' to 'excerpts' to 
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emphasize the missing portions of a valid DAVE-ML file. Corrected units in check-case 
examples to match the draft AIAA standard. 

• Removed the symmetric attribute of the uniformPDF sub-element; this attribute was 
redundant as symmetric distribution is implied with a single bounds sub-element, and 
asymmetric is implied by two bounds sub-elements. Kudos to Dan Newman and Dennis 
Linse for catching the inconsistent examples and for suggesting this convention. 

• Corrected tire DTD by reversing the definition of tire floor and ceiling values of 
the interpolate attribute of the independentVarPts element; also corrected the 
correlated uncertainty example. Thanks to Dan Newman for catching both of these problems 
in 2.0 RC1. 

• Corrected the DTD so that only one checkData element is allowed (but it can have 
multiple different staticShot test conditions). Thanks to Dan and Dennis for reporting this 
inconsistency betw een the reference manual and the DTD. 

• Added a description sub-clement to the staticShot element in response to a 
suggestion by Dennis I.insc: and added a typical description to example listings. 

• Added a section about namespaces and removed the hard link in the DTD that incorrectly set 
the namespace for the calculation element. 

• Added new multi-purpose creationDate clement to replace the single-purpose 
f ileCreationDate and functionCreationDate elements, at the suggestion of 
Dennis I.insc of SAIC. f ileCreationDate and functionCreationDate arenow 
deprecated. 

• Corrected descriptions of ungriddedTableDef and griddedTablaDef to reflect the 
possible use of an internal function element; previously the descriptions implied that these 
elements were only specified external to functions and thus tire utID and gtID attributes, 
respectively, were required. Thanks to Dennis Linse for the conection. 

• Depicted provenanceRef as an option to the provenance sub-element for 
griddedTableDef , ungriddedTableDef , and function elements in the nanative 
part of this manual (it was described conectly in tire reference section). Also added both 
provenance and provenanceRef as optional sub-elements of the variableDef and 
checkData elements. Thanks to Dennis Linse for the correction. 

• Added '(Deprecated]' to the description of griddedTable, ungriddedTable, and 
conf idenceBound elements for consistency; these were previously deprecated but not 
marked clearly in each element's 'purpose' section. Thanks to Dennis Linse for the suggestion. 

• Updated the acknowledgment paragraph of the DTD; significantly reformatted the .PDF 
version of this document, and added section numbers to all versions. 

1.3. Changes since version 1.9b3 

• Added ceiling and floor enumeration selections to interpolate attribute of 
independentVarPts and independentVarRef elements at the suggestions of Geoff 
Brian, Giovanni Cignoni, Randy Brumbaugh, and Dan Newman. 
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• Added five uncertainty examples. 

• Cleaned up all FIXME and BUG notes. 

• Corrected and expanded the labels on the DAVE-ML excerpt figure. 

1.4. Changes since version 1.9b2 

• Corrected link to the DAVE-ML exchange test f Jackson04] paper. 

• Added discrete enumeration selection to interpolate attribute of 
independent VarPts and independentVarRef elements at the suggestion of Geoff 
Brian, Australian Defence Science and Technology Organisation (DSTO). 

• Added a section and a variableDef example on extending the MathML-2 function set 
with atem2. 

• Removed all xns attributes from examples. 

• Emphasized that it is a good practice to provide variableDefs in sorted sequence. 

1.5. Changes since version 1.8b1 

• Added a quadraticSpline enumerated value to the interpolate attributes of tire 
independentVarPts and independentVarRef elements (in response to a request 
from Geoff Brian of DSTO) and fixed a typographical error in cubicSpline attribute string. 
Added reference to Wikipedia article on spline interpolation [http://cn.wikipedia.org/wikk 
Spline interpolation], 

• Added a classification attribute to tire reference element and added a date 
attribute to the modi f icat ionRecord element, at the suggestion of Geoff Brian of DSTO. 

• Added 2D and 3D ungridded table examples and figures and corrected a typographical error 
in the ungridded table definition syntax (thanks to Dr. Peter Grant of U. Toronto's ETTAS and 
Geoff Brian of DSTO). 

• Reintroduced <!ENTITY> to include MathME-2 D I D (complete) in the body of this DTD. 
This entity definition quietly went away in version 1.6 due to a misunderstanding of the proper 
way to include external DTDs. It was reintroduced to assist with validating parsers. 

• Added a de script ion sub-element to the provenance element, so tire provenance entry 
can contain more information about change justification documents and made provenance 
or provenanceRef acceptable sub-elements to variableDef and checkData 
elements at tire request of Geoff Brian of DSTO. 

1.6. Changes since version 1.7b1 

• Renamed docID attribute to ref ID in the modif icationRecord so the attribute name 
is consistent: the docID attribute is deprecated but remains in place for compatibility with 
older documents. 
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• Added correlatesWith and correlation sub-eleinents of uncertainty element 
to allow for multiple-dimensioned linear correlation of uncertainty of selected functions and 
variables. 

• Added a new element contactlnf o, to replace the single address clement. This format 
supports multiple ways to indicate how to contact the author of a document or reference, 
address is deprecated but is retained for backwards compatibility. This element also 
replaces the email and xns attributes of author. 

• Fixed a typographical error in ungriddedTableRef element: incorrect gtID attribute 
corrected to utID. 

• Allowed multiple author elements wherever only one had been allowed before. 

• Added a new tag, isStdAIAA , to indicate that a variableDef refers to one of the standard 
AIAA variables. 

• Removed [un] griddedTable [Ref | Def ] sub-elements of the conf idenceBound 
element since this leads to circular logic. 

• Changed SYSTEM ID to reflect new davcml.nasa.gov domain availability'. 

• Removed true email from examples to protect privacy of individual contributors. 

• Added a new attribute, interpolate, to the independentVarPts clement to indicate 
whether the table interpolation should be linear or cubic spline in the given dimension 
(modified to include quadratic in version 1.9], 

• Added a new tag, isState, to indicate that a variableDef refers to a state variable in 
tile model. 

• Added a new tag, isStateDeriv, to indicate that a variableDef refers to a state 
derivative variable in the model. 

1.7. Changes since version 1.6b1 

Added checkData and associated elements. Added description sub-element to 

reference element. 

1.8. Changes since version 1.5b3 

Added an uncertainty element. Emphasized MathML-2 content markup over presentation 

markup. Fixed several grammatical and typographical errors and added figure 1. Added ISO 

8601 (Dates and Times) reference. 

1.9. Changes since version 1.5b2 

• Added Bill Cleveland (NASA Ames Research Center's SimLab) and Brent York (NAY AIR's 
Manned Flight Simulator) to the acknow ledgments section, to thank them for their pioneering 
initial trials of DAVE-ML 
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• Added provenanceRef element and changed all parents (specifically function, 
griddedTableDef and ungriddedTableDef elements) of provenance elements 
to enable them to use a provenanceRef reference instead to eliminate duplicate 
provenance elements. 

• Realization dawned that there was little difference between griddedTables and 
griddedTableDefs but that the latter was more flexible (ditto ungriddedTables 
and ungriddedTableDefs). By making the gtID and utID attributes 'implied’ instead 
of 'required.' we can use the Def versions in both referenced-table and embedded-table 
functions. Thus the original griddedTable and ungriddedTable elements have 
been marked as 'deprecated.' They are still supported in this DTD for backwards compatibility 
but should be avoided in future use. ihe easiest way to modify older DAVE-ML models would 
be to rename all griddedTables as griddedTableDefs. 

1.10. Changes since version 1.5b 

• Fixed typographical errors pointed out by Bill Cleveland. 

• Added fileVersion element to fileHeader element, so each version of a particular 
DAVEf unc model can be uniquely identified. Formal of the version identifier is undefined. 

• Added an email attribute to the author element. The Extensible Name Service (xns [http l// 
www.xns.org]) standard does not appear to be catching on as rapidly as hoped, so a static e- 
mail link will have to do for now, at least until the replacement XRI technology' is more widely 
adopted. 

• Added a mandatory varlD attribute to both independentVarPts and 
dependentVarPts so these can be associated with an input and output signal name 
(variableDef ), respectively. 

• Added an optional extraDocRef element to the modi fi cat ionRecord element so 
more than one document can be associated with each modification event. If only one document 
needs to be referenced, use of the optional reflD in the modi fi cat ionRecord itself will 
suffice. 
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2. Introduction 

This document describes the formal for DAVE-ML model definition files. DAVE-ML is a 
proposal standard format for the interchange of aerospace vehicle flight dynamics models. The 
intent of DAVE-ML is to significantly expedite the process of re-hosting a simulation model 
from one facility to another and function as an improved method to promulgate changes to a 
particular model between various facilities. 

DAVE-ML is based on the Extensible Markup Language (XML), a World-Wide W eb 
Consortium (W3C) standard. More information on XML is available here [http://www.w3.org/ 
XML/]. 

Tile exchange of aerospace vehicle flight dynamics models may derive many benefits from the 
application of XML in general, and DAVE-ML in particular: 

• Provides a human-readable text description of the model 

• Provides an unambiguous machine-readable model description, suitable for conversion into 
programming language or direct import into object-oriented data structures at run-time 

• Allows use of the same source file for computer-aided design and real-time piloted simulation 

• Rased on open, non-proprictarv, standards that arc language- and facility-independent 

• Allows inclusion of statistical properties, such as confidence bounds and uncertainty ranges, 
suitable for Monte Carlo or other statistical analysis of the model 

• Complies with emerging AIAA simulation data standards 

• Represents a self-contained, complete, archhable data package, including references to 
reports, wind-tunnel tests, author contact information, and data provenance 

• Is self-documenting and easily convertible to on-line and hard-copy documentation 

A more complete discussion on the benefits and design of DAVE-ML can be found at the DAVE- 
ML web site: http://daveml.org [http://davcml.org] 
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3. Purpose 

DAVE-ML is intended to encode (for exchange and long-term archive) an entire flight vehicle 
dynamic simulation data package, as is traditionally done in initial delivery and updates to 
engineering development, flight training, and accident investigation simulations. It is intended to 
provide a programming-languagc-indcpcndcnt representation of tire aerodynamic, mass inertia, 
landing gear, propulsion, and guidance, navigation and control laws for a particular vehicle. 

Traditionally, flight simulation data packages are often a combination of paper documents and 
data files on magnetic or optical media. This collection of information is very much vendor- 
specific and is often incomplete or inconsistent. Many times, the preparing facility makes 
incorrect assumptions about how the receiving facility's simulation environment is structured. 
As a result, the re-hosting of the dynamic flight model by the receiving facility can take weeks 
or longer as the receiving facility stall learns the contents and arrangement of the data package, 
the model structure, the various data formats, and variable names/units sign conventions. The 
staff then spends additional time running check-cases (if any were included in the transmittal) 
and tracking down inevitable differences in results. 

There arc obvious benefits to automating most of this tedious, manual process. Often, when a pair 
of facilities has already exchanged one model, the transmission of another model is much faster 
since the receiving facility will probably have devised some scripts and processes to convert tire 
data (both model and check-case data). 

The putpose of DAVE-ML is to develop a common exchange format for these flight dynamic 
models. The advantage gained is to enable any simulation facility or laboratory, after having 
written a DAVE-ML import and or export script, to automatically receive and/or transmit such 
packages (and updates to those packages) rapidly with other DAVF.-MI .-compliant facilities. 

To accomplish this goal, the DAVE-ML project is starting with the bulkiest part of most aircraft 
simulation packages: the aerodynamics model. This initial version of DAVE-ML can be used to 
transport a complete aerodynamics modek including descriptions of the aerodynamic build-up 
equations and data tables, and include references to the documentation about tire aerodynamics 
model and check-case data. This format also lends itself to any static subsystem model (i.e. 
one that contains no state vector) such as tire mass and inertia model, or a weapons load-out 
model, or perhaps a navigational database, lire only requirement is that model outputs must be 
unambiguously defined in tarns of inputs, with no past history (state) information required. 

DAVE-ML forms the encoding portion of tire Flight Simulation Model Exchange Standard, BSR/ 
MAAS-1 19-20 10 (currently in draft form). More information is available at tire S-119 web site 
IAIAA10], 
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4. Background 

The idea of a universally understood flight dynamics data package has been discussed for at 
least two decades within the AIAA technical committees [Hildreth94], [Hildrelh98 1. There have 
been proposals in die past to standardize on Fortran as w'ell as proprietary, vendor-specified 
modeling packages, including graphical ones. The National Aerospace Plane (NASP) Program, 
under the guidance of Larry Schilling of NASA Dryden Flight Research Center, developed a 
hybrid Web- and secure-FTP-based system for exchanging NASP subsystem models as well as 
a naming convention for variables, file names, and odier simulation components in the early 
1990s. Some other simulation standards have subsequently been proposed by the AIAA and are 
under active consideration at tliis writing [AIAA10]. 

4.1. Existing standards 

Tlie AIAA has published a Recommended Practice concerning sign conventions, axes systems, 
and symbolic notation for flight-vehicle models [AIAA92], 

The AIAA Modeling and Simulation Technical Committee has prepared a draft standard for 
the exchange of simulation modeling data. This includes a methodology for accomplishing 
the gradual standardization of simulation model components, a mechanism for standardizing 
variable names within math models, and proposed Hierarchical Data Format 5 (IIDF5) as the 
data format. This document is included as an Annex to the standard [AIAA01], [AIAA03], 
[AIAA10], 

4.2. DAVE-ML proposal 

In a 2002 AIAA paper, Jackson and Hildreth proposed using XML to exchange flight dynamic 
models [Jackson02]. This paper gave outlines for how such a standard could be accomplished, 
and provided a business justification for pursuing such a goal. 

The 2002 proposal included several key aspects from the draft standard, including allow ing use 
of a standard variable-name convention and data table schema and including traceability for each 
data point back to a referenced document or change order. 

In a subsequent paper. Jackson. I Iildreth, York and Cleveland [Jackson04] reported on the results 
of a demonstration using DAVE-ML to exchange two aerodynamic models between simulation 
facilities, show ing the feasibility of the idea. 

4.3. Recent applications 

Several successful applications of DAVE-ML have been reported. These include the adoption 
of DAVE-ML by the Australian DSTO for threat models [Brian05] and the U.S. Navy for their 
Next Generation Threat System [HildrethOS]. Import tools to allow the direct use of DAVE- 
ML models (without recompilation) in real-time piloted simulations have been reported by 
NASA Langley Research Center (LaRC) [IIill07] and at NASA Ames Research Center (ARC). 
Some interest has been generated within NASA’s Orion Project as well [AcevedoOTj. Other 
applications include TSONT, a trajectory optimization tool ([Durak06]) and aircraft engine 
simulations ([Lin04]). 
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DAVE-ML format for models has also been supported by the GeneSim [http:// 
genesim.sourceforge.net] Project, which is providing open-source utility programs that realize a 
DAVE-ML model in object-oriented source code such as C++, Java and CU. 
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5. Supporting technologies 

DAVE-ML relics on MathML. version 2.0, to define mathematical relationships. MathML-2 is 
an XML grammar lor describing mathematics as a basis for machine- to-machine communication. 
It is used in DAVE-ML to describe relationships between variables and function tables and may 
also be used for providing high-quality typeset documentation fiom the DAVE-ML source files. 
More information is available at the MathML-2 home web page, found at http://www.w3.org/ 
Math/. 

MathML-2 provides a mostly complete set of mathematical functions, including trigonometric, 
exponential and switching functions. One function that is available in most programming 
languages and computer-aided design tools but is missing from MathML-2 is the two-argument 
arctangent function which provides a continuous angle calculation by comparing the sine and 
cosine components of a 2D coordinate set. DAVE-ML provides a means of extending MathML-2 
for a predefined set of functions (currently only the atcm2 function is defined). Thus, a DAVE- 
ML-compliant processing tool should recognize this extension (which is accomplished bv 
using the MathML-2 csymbol element). See Section 6.2.2 (p. 23) for a discussion and 
Example 6 (p. 29). 
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6. Major elements 

At present, only one major element of DAVE-ML has been defined: the function definition 
element, or DAVEfunc. DAVEfunc is used to describe static models such as aerodynamic 
and inertia mass models, where an internal state is not included. Static check-eases am also be 
provided for verification of proper implementation. 

Other major elements are envisioned to describe dynamic portions of the vehicle model (such 
as propulsion, landing gear, control systems, etc.) and dynamic check-case (time history) data. 
Ultimately DAVE-ML should be oipable of describing a complete flight-dynamics model with 
sufficient data to validate the proper implementation thereof. 

6.1. The DAVEfunc major element 

The DAVEfunc element contains both data tables and equations for a particular static model. A 
DAVEfunc element is broken into six components: a file header, variable definitions, breakpoint 
definitions, table definitions, function definitions and optional check-cases. This decomposition 
reflects common practice in engineering development flight-simulation models in which the 
aerodynamic database is usually captured in multi-dimensional, linearly interpolated function 
tables. The inputs to these tables are usually state variables of the simulation (such as Mach 
number or angle-of-attack). The outputs from these interpolated tables are combined to represent 
forces and moments acting on tire vehicle due to aerodynamics. 

It is possible, using DAVEfunc and MathML-2 elements, to completely define an aerodynamic 
model w ithout use of function tables (by mathematical combinations of input variables, such as 
a polynomial model) but this is not yet common in the American flight-simulation industry. 

A f i 1 eHe ade r element is included to give background and reference data for the represented 
model. 

Variables, or more properly signals, are used to route inputs and calculations through the 
subsystem model into outputs. Each variable is defined with a variableDef element. 
Variables can be thought of as parameters in a computer program or signal paths on a 
block diagram. They can be inputs to the subsystem model, constant values, outputs from 
the model, and/or the results of intermediate calculations. Variables must be defined for each 
input and output of any function element as well as any input or output of the subsystem 
represented. MathML-2 [http://www.w3.org/Math] content markup can be used to define 
constant, intermediate, or output variables as mathematical combination of constant values, 
function table outputs, and other variables, but any presentation markup is not required and 
should be ignored by the processing application (except as required to generate documentation). 
Variables also represent the current value of a function (the dependentVariableDef in a 
function definition) so the output of functions can be used as inputs to other variables or 
functions. 

Breakpoint definitions, captured in breakpointDef elements, consist of a list of 
monotonically increasing floating-point values separated by commas or white space. fhese sets 
are referenced by "gridded" function table definitions and may be referenced by more than one 
function definition. 

Function table definitions, described by griddedTableDef and ungriddedTableDef 
elements, generally contain the bulk of data points in an aerodynamics model, and typically 
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represent a smooth hyper-surface representing the value of some aerodynamic non-dimensional 
coefficient as a function of one or more vehicle states (typically Mach number, angle-of- 
attack, control surface deflection, and'or angular body rates). These function tables can be either 
"gridded," meaning the function has a value at every intersection of each dimension's breakpoint, 
or "ungridded," meaning each data point has a specified coordinate location in n-space. The same 
table can be reused in sever al functions, such as a left- and right-aileron moment contribution. 

Function definitions (described by function elements) connect breakpoint sets and data tables 
to define how an output signal (or dependent variable) should vary with one or more input 
signals (or independent variables). The valid ranges of input-signal magnitudes, along with 
extrapolation requirements for out-of-range inputs, can be defined. There is no limit to tire 
number of independent variables, or function dimensionality', of the function. 

Check-case data (described by a single checkData element) can be included to provide 
information to automatically verify tire proper implementation of tire model by the recipient. 
Multiple check-cases can (and should) be specified using multiple staticShot test-case 
definitions, as well as optional internal signal values within the model to assist in debugging an 
instantiation of the model by tire recipient 

Figure 1 (p. 18) contains excerpts from an example model, showing five of the six major 
parts of a DAVE-ML file. 
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Figure 1. Excerpts from an example DAVE-ML file 

A simpler version of a function is ax'ailable in which the dependent variable breakpoint 
values and dependent output values are specified directly inside the function body. This 
may be preferred for models that do not reuse function or breakpoint data. 

A third form of function is to give the gridded table values or ungridded table values inside 
the function body, but refer to externally defined breakpoint sets. This allows reuse of the 
breakpoint sets by other functions but keeps the table data private. 

6.2. Schematic overview of DAVEfunc 

Shown below are schematic overviews of the various elements currently available in DAVEfunc. 
Each element is described in detail in Section 8 (p. 60) later in this document. The following 
key is used to describe the elements and associated attributes. 
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Key: 

element name : mandatory_at tributes , [optional_attributes] 
ma nda t o ry_ s i ng 1 e_s ub - e 1 em ent 

optional_single_sub- element? {editorial comment} 

( choice_l_sub- element | choice_2_sub- element ) 
zero_or_more_sub-elements * 
one_or_mor e_sub - el ement s+ 

(character data) implies UNICODE text information 


The DAVEfunc clement has six possible sub-elements: 


DAVEfunc : 

tileHeader 
variableDef. 
breakpoint Def* 
g ri ddedTabl eDe f • 
ung nddcdTabl eDef* 
f unction’ 
checkData? 


DAVEfunc sub-elements: 

f ileHeader 


variableDef 


breakpointDef 


griddedTableDef 


This mandatory element contains information about the 
origin and development of this model. 

Each DAVEfunc model must contain at least one signal 
path (such as a constant output value). Each input, output 
or internal signal used by the model must be specified in 
a separate variableDef. 

A signal can have only a single origin (an input block, 
a calculation, or a function output) but can be used 
(referenced) more than once as an input to one or more 
functions, signal calculations, and'or as a model output. 

In DAVE-ML 2.0, all signals are real and scalar. 

The variableDefs should appear in calculation order: 
that is, a variableDef should not appear before the 
definitions of variables upon which it is dependent. This 
is good practice since doing so avoids a circular reference. 
If a variable depends upon the output (dependentVar ) 
of a function it can be assumed that dependence has 
been met since function definitions appear later in the 
DAVEfunc element. 

A DAVEfunc model can contain zero. one. or more 
breakpoint set definitions. These definitions can be 
shared among several gridded function tables. Breakpoint 
definitions can appear in any order. 

A DAVEfunc model can contain zero, one, or more 
gridded nonlinear function table definitions. Each table 
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must be used by multiple function definition if desired 
for efficiency. Alternatively, some or all functions 
in a model can specify their tables internally with an 
embedded griddedTableDef element. 

A gridded function table contains dependent values, or 
data points, corresponding to the value of a function at 
die intersection of one or more breakpoint sets (one for 
each dimension of the table). The independent values 
(coordinates or breakpoint sets) arc not stored w ithin the 
gridded table definition but are referenced by die parent 
function. This allows a function table to be supported by 
more than one set of breakpoint values (such as left- and 
right-aileron deflections). 

ungriddedTableDef A DAVEfiinc model can contain zero, one, or more 

ungridded nonlinear function tabic definitions. Unlike a 
rectangularly gridded table, an ungridded table specifies 
dab points as individual sets of independent and 
dependent values. Each tabic must be used by at least 
one but can be used by multiple function definitions 
if necessary for efficiency. Alternatively, functions 
can retain their tables internally with a ungriddedi’able 
clement without sharing the table values widt other 
functions. 

Ungridded tabic values arc specified as a single (unsorted) 
list of independent variable (input) values and associated 
dependent variable (output) values. While the list is not 
sorted, the order of the independent variable inputs is 
important and must match the order given in the parent 
function. Thus. functions that share an ungridded table 
definition must have the same ordering of independent 
variables. 

The method of interpolating the ungridded data is not 
specified. 

function A function ties together breakpoint sets (for gridded- 

table nonlinear functions), function values (either 
internally or by reference to table definitions), and the 
input- and output-variable signal definitions, as show n in 
Figure 1 (p. 18) Functions also include provenance, 
or background history, of the function data such as wind 
tunnel lest or other source information. 

checkData This optional element contains information allowing the 

model to be automatically verified after implementation 
by the receiving party. 
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An example of each of these sub-elements is given below. Complete descriptions of each element 
in detail are found in Section 8 (p. 60). 

6.2.1. The file header element 

The fileHeader element contains information about the source of the data contained 
within the DAVEf unc major element, including the author, creation date, description, reference 
information, and modification history. 


CileHeader : [namej 

author* : name, org, [email] 

contactlnfo* s [contact In foTypa, contact Location] 

{text describing contact information for author} 
creationDate : date {in ISO 8601 YYYY-MM-DD format} 
f ileVersion? 

{file version identifier} 
description? 

{textual description of model} 

reference* : ref ID, author, title, date, [classification, accession, href] 
description? : 

{textual information about reference} 
modi fi cat ionRe cord* i modID, date, [refID] 
author* t name, org, [email] 

contactlnfo* : [contact In foType, contact Location] 

{text describing contact information for author} 
description? 

{textual description of modification} 
extraDocRef* : refID 
provenance* : 

author* t name, org, [email] 

contactlnfo* : [contact In foType, contact Location] 

{text describing contact information for author} 
creationDate : date {in ISO 8601 YYYY-MM-DD format} 
document Ref* : [docID,] refID 
modificationRef* s modID 
description? 

{textual description of the background of the model} 


fileHeader sub-elements: 

author 

creationDate 
f ileVersion 

description 

reference 


Name, organization, optional email address and other 
contact information for each author. 

Creation date of this file. See Section 6.5.4 (p. 56)for 
the recommended format for encoding dates. 

A string that indicates the version of the document. No 
convention is specified for the format, but a good practice 
would include an automated revision number from a 
version control system. 

An optional hut recommended text description: what does 
tli is DAVE-ML file represent? 

An optional list of one or more references with a 
document-unique ID (must begin with alpha character), 
author, title, date, and optional accession and URL of the 
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reference. This sub-element can include a description of 
the reference. 

modif icationRecord An optional list of one or more modifications with 

optional reference IDs, as well as author information 
and descriptions for each modification record. These 
modifications are referred to by individual function tables 
and/or data points, using the AIAA modification letter 
convention. If more titan one document is associated with 
the modification, multiple sub-element extraDocRefs 
may be used in place of the modif icationRecord's 
ref ID attribute. 

provenance An optional list of one or more provenance elements 

allows the author to describe the source and history 
of the data within this model. Since the model may 
be constructed from several sources, more than one 
provenance may be provided, one for each source of 
data. Use of a provID attribute in the f ileHeader is 
unnecessary since this provenance applies to the entire 
model unless otherwise specified. 

Example 1. An excerpt with an example of a f ileHeader element 


<l-- — - — -- 

cl-. — file header 

< 1 -. ............... 


> o 


<£ileHeader> ® 

<author name«"Bruce Jackson” org-"NASA Langley Research Center"> 

■ccontactlnfo contact In foType- 'address • con tact Location- 'prof essional •> 

MS 308 NASA, Hampton, VA 23681 
</contactInfo> 

•ccontactlnfo contact infoType- 'email ’ contact Locat ion-'prof essional • > 
Bruce . Jackson©nospam . nasa . gov 
</contactInfo> 

</author> 

<creationDate date«"2003-03-18"/> © 

<fileVersion>$Revision: 1.24 $</fileVersion> 0 
<description> 

Version 2.0 aero model for HL-2Q lifting body, as described in 
NASA TM-107580. This aero model was used for HL-20 approach and 
landing studies at NASA Langley Research Center during 1989-1995 
and for follow-on studies at NASA Johnson Space Center in 1994 
and NASA Ames Research Center in 2001. This DAVE-ML version was 
created in March 2003 by Bruce Jackson to demonstrate DAVE-ML. 
</description> 

reference reflD*»"REF0l " © 

author«*Jackson, E. Bruce; Cruz, Christopher I. & and Ragsdale, W. A." 
title- "Real -Time Simulation Model of the HL-20 Lifting Body" 
access ion = "NASA TM-107580" 
date- "1992- 07-01" 
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/> 


^reference ref IB="REF02 " 

author= "Cleveland, William B. <nospam«mail.arc.nasa.gov>* 
title- "Possible Typo in HL20_aero.xml • 
access ion* " ema il ■ 
date* *200 3- 08-19* 


<modifi cat ionRe cord modID*"A" refID»"REF02"> G> 

<author name-"Bruce Jackson" org-"NASA Langley Research Center" > 

<contactInfo contact Inf oType* ’address ' contact Locations 'prof essional ' > 
MS 308 NASA, Hampton, VA 23681 
< /contact In fo> 

</author> 

<description> 

Revision 1.24s Fixed typo in CLRUDO function description which 
gave dependent signal name as "CLRUD1." Bill Cleveland of NASA 
Ames caught this in his xml2ftp script. Also made use of l . Sb2 
fileHeader fields and changed date formats to comply with 
convention. 

</description> 

< / mod i f i ca t ionReco rd > 

</ f i leHeader» 


O Use of comments make models more readable by humans. 

© Start of the f i leHeader element. 

© Creation date of file, in ISO-8601 format. See Section 6.5.4 (p. 56) 

O In this example, the revision number is automatically inserted by a version control system. 

@ All documents referenced by notation throughout the file should be described in the 

fileHeader as reference elements. 

Q All modifications made to the contents of this file should be listed in the fileHeader as 
modi f i cat ionRecord sub-elements for easy reference by later modif icat ionRe f 
elements. 

6.2.2. The variable definition element 

The variableDef element is used to define each constant, parameter, or variable used within 
or generated bv the defined subsystem model. It contains attributes including the variable 
name (used for documentation), an internal and unique varlD identifier (used for linking 
inputs, functions and outputs), the units of measure of the v ariable, and optional axis system, 
sign convention, alias, and symbol declarations. Optional sub-elements include a written text 
description and a mathematical description, in MathML-2 content markup, of the calculations 
needed to derive the variable from other variables or function table outputs. Optional sub- 
eleinenl isOutput, serves to indicate an intermediate calculation that should be brought out 
to the rest of the simulation. Another optional sub-element, isStdAIAA. indicates the variable 
name is defined in the AIAA simulation standards document. Another optional sub-element, 
uncertainty, captures the statistical properties of a (normally constant) parameter. 

Other optional sub-elements are provided to identify inputs, disturbances, and simulation control 
parameters, as well as the ability to identify a variable as a state or state derivative for linear 
model purposes. 

There must be a single variableDef for each and every input, output or intermediate constant 
or variable within the DAVKfunc model. 
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variableDef = name, varlD, units, TaxisSystem, sign, alias, symbol, initialValue] 
description? : 

{description character data} 

< 

provenanceRef : provID 
OR 

provenance : [provID] 

author* r name, org, lemailj 

contact Info* : (contact In foType, contact Location] 

{text describing contact information} 
creationDate : date {in YYYY-MM-DD format} 
document Ref* : [docID,] ref ID 
modificationRef* ; modID 
description? 

)? 

calculation? s 

math {defined in MathML-2 DTD} 

(islnput I iscontrol | isDisturbance) ? 

isState? 

isStateDeriv? 

isOutput ? 

isStdAIAA? 

uncertainty? : effect 

(normalPDF : numSigmas) | {uniformPDF : bounds*) 


variableDef attributes: 

name 

varlD 

units 

axisSystem 


sign 


alias 


symbol 


A UNICODE name lor the variable (may be the same- 
string as the varlD). 

An internal identifier that is unique within the file. 

The units-of-mcasurc for the signal, using the AIAA 
standard units convention [AIAA 10]. 

An optional indicator of the axis system (body, inertial, 
etc.) in which the signal is measured. Sec [AIAA 10] or 
Section 6.5 (p. 55)bclow lor recommended practice 
for nomenclature. 

An optional indicator of which direction is considered 
positive (+RWD, +UP, etc.). Sec [AIAA10] or the section 
on Section 6.5 (p. 55) below' for recommended 
practice for abbreviations. 

An optional, facility-specific variable name, perhaps used 
in the equations of motion or control system model, that 
docs not conform to the AIAA standard for variable 
names. Use of this attribute is discouraged for portability 
reasons. 

A UNICODE Greek symbol for the signal [to be 
superseded with more formal MathML or TeX element in 
a later release]. 
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initialValue An optional initial value for the parameter. This is 

normally specified for constant parameters only. 


variableDef sub-elements: 

description 

provenance 


calculation 


islnput 


isControl 


isDisturbance 


isOutput 


An optional text description of the variable. 

The optional provenance element allows the author to 
describe the source and history of the data within this 
variableDef. Alternatively, a provenanceRef 
reference can be made to a previously defined 
provenance. 

An optional container for the MathML-2 content markup 
dial describes how this variable is calculated from other 
variables or function table outputs. This element contains 
a single math element which is defined in the MathML-2 
markup language [http://www.w3.org/Math], 

A MathML-2 calculation can include both constants 
(using the content numeric cn element) and references 
to other variables internal to the parent DAVEfunc 
description. The variables (which can include the 
output, or dependent variable of a function table) 
are identified using its varlD attribute string in the 
appropriate MathML content identifier (ci) element of 
tire expression. 

Examples of MathML expressions appear later in this 
reference. 

This optional element, if present, signifies that this 
variable is an input to the model, such as a pilot inceptor 
deflection or Mach number. Useful for linear model 
extraction tools. It must not be the result of a calculation 
or be cited as the dependent variable of a function. 

This optional element, if present, signifies that this 
variable is a simulation control parameter, such as a trim 
flag or simulation time step measurement. Simulation 
control parameters should have no influence on the 
dynamic behavior of the model and should be ignored by 
a linear model extraction tool. 

This optional element, if present, signifies that this 
variable represents an external disturbance input to the 
model; this is useful for linear model extraction tools to 
partition this input separately from the other model inputs. 

This optional element if present, signifies that this 
variable needs to be passed as an output. How this is 
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isStdAIAA 


isState 


isStateDeriv 


accomplished is up to the implementer. Unless specified 
by this element, a variable is considered an output only 
if it is the result of a calculation or function AND is not 
used elsewhere in the DAVEfunc. 

This optional clement, if present, signifies that this 
variable is one of the standard AIAA simulation variable 
names that are defined as Annex A to [AIAA 10). Such 
identification should make it easier for the importing 
process to connect this variable (probably an input or 
output of the model) to the appropriate variable to from 
tlie user's simulation framework. 

This optional element, if present, signifies that this 
variable selves as a state of the model. 

This optional element, if present, signifies that this 
variable serves as a state derivative of the model. 


uncertainty This optional element, if present, describes the 

uncertainty of this parameter. See the section on Statistics 
below for more information about this element. 


Example 2. An example or two variableDe f elements defining input signals 

In this example . two input variables are defined: XMACH and DBFLL. These two variables are 
inputs to a table lookup function shown in Example 11 (p. 41 ) below. 


<i-. --» 

<1-. ... ................. VARIABLE DEFINITIONS ................ 

.......................... --> 


.................. -- > 

<1-- Input variables - - > 

< 1 -- --> 

cvariableDef name»"mach"0 varlD- “XMACH”© units«"nd" symbol«"M"> 
<description> 

Mach number (dimensionless) 

< /descript ion > 

<islnput/t-© 

<isStdAIAA/ >© 

</variableDef > 


cvariableDef name "dbfll" varlD "DBFLL" units "deg"© sign="TED“® 
symbol -"&#x3B4 ;bfl] 

<description> 

Lower left body flap deflection, deg, positive trailing- edge- down (so 
deflections are 

always zero or positive) . 

</description> 

<isInput/> 

</variableDef > 
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O The name attribute is intended for humans to read, perhaps as the signal name in a wiring 
diagram. Note that "machNumber" is one of the standard AIAA simulation variable names. 
© The varlD attribute is intended for the processing application to read. This is an internal 
identifier that must be unique within this model. 

© The optional i slnput attribute indicates this variable should be treated as an input to the 
model for model hierarchy and linear model extraction (for example). 

© The optional isStdAIAA sub-clement indicates this signal is one of the predefined 
standard variables that most simulation facilities define in their equations of motion code. 
Tile name attribute should correspond to the standard AIAA parameter name from Annex 
Aof[AIAA10] or subsequent standards document 
© The mandatory units attribute describes the units of measure of the variable. Sec 
Section 6.5.6 (p. 56) below' for a recommended list of units-of-measure abbreviations. 

Q The optional sign attribute describes the sign convention that applies to this variable. 
In this case, the lower-left body-flap is positive with trailing-edge-down deflection. Sec 
Section 6.5.5 (p. 56) below for a recommended list of sign abbreviations. 

© the optional symbol attribute allows a UNICODE character string that might be used for 
this variable in a symbols listing. 

Example 3. A simple local variable definition example 

This DAVE-ML excerpt defines CLBFLLO which is the dependent variable (output) from a table 
lookup function (shown later in Example 11 (p. 41). It is subsequently used in the calculation 
of the lower-lell body flap lift coefficient (shown in Example 4 (p. 27)). 


< I - - mmmm-mmmmmmm-mmmmm -- > 

<1-- Local variables 

cl -- ------------------ — > 

cl-- PRELIMINARY BUILDUP EQUATIONS --> 

<1-- LOWER LEFT BODY FLAP CONTRIBUTIONS 

<1-- table output signal --> 

cvariableDef name- w CLdbfll_0" varID- ,, CLBFLLO ,, units-"nd*> 
<description> 

Output of CLBFLLO function; lift force contribution of 
lower left body flap deflection due to alpha “0 (constant 
term) . 

</description> 

</variableDef > 


Since this signal is not flagged as an input, control, disturbance or output, this variable is an 
intermediate signal local to this model. 

Example 4. A more complete variableDef example with a calculation element 

In this example, the local variable CLBFLL is defined as a calculated quantity, based on several 
other input or local variables including the CLBFLLO function output variable defined in tire 
previous example (p. 27) Note the description element is used to describe the equation 
in Fortran-ish human-readable text. The calculation clement describes this same equation in 
MathML-2 content markup syntax; this portion should be used by parsing applications to create 
either source code, documentation, or run-time calculation structures. 

<1-- lower left body flap lift buildup 

<variabl«Def natne-”CLdbfll* varlD-" CLBFLL" units-*nd"> 
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<description> 

Lift contribution of lower left body flap deflection 
CLdbfll - CLdbf 11_0 ♦ alpha* (CLdbfll_l t alpha* (CLdbfll_2 
+ alpha *CLdbfll_3 ) } O 

</descript ion> 

<calculation> © 

<math xmlns-''http: //www.w3 .org/1998/Math/MathML"> 

< apply > © 

<plus/> 

<ci>CLBPLLO</ci> O 
<apply> 

<time«/> 

<ci>ALP</ci> 

<apply> 

<plus/> 

<ci >CLBFLL1</ ci> 

<apply> 

<times/> 

<ci >ALP</ci> 

< apply > 

<plus/ > 

<ci >CLBFLL2</ci > 

<apply> © 

<t imes/> 

<ci>ALP«/ci> 

<ci>CLBFLL3</ci > 

< /apply > <1-- a* o3 -->© 

</apply> <1-- (c2 ♦ a*c3) 

</apply> <1-- a* (c2 + a*c3) --> 

</apply> <!-- (cl t a* (c2 + a*c3)) --> 

c/apply> <1-- a* (cl ♦ a* (c2 + a*c3)) --> 

</apply> <i-- cO + a* (cl + a*(c2 + a*c3)> 

</math> 

</calculation> 

</variableDef> 


O Tliis Fortran-ish equation, located in the description element, is provided in this 
example for the benefit of human readers: it should not parsed by the processing application. 

@ A calculation element always embeds a MathML-2 math element; note the definition 
of the MathML-2 namespace. 

© F.ach apply tag pair surrounds a math operation (in this example, a plus operator) and 
the arguments to that operation (in this case, a variable CLBFLL defined elsew here is added 
to the results of the nested apply operation). 

O The content identifier (ci) MathMT, -2 element gives the varlD of the previously defined 
variables used in tliis equation; this variable represents the output of the CLBFLLO function 
found in F.xample 1 1 (p. 41 ) that is captured in the CLBFLLO variable defined in 
Example 3 (p. 27) The other ci elements arc not defined in this manual hut arc defined 
in the full model. 

© Inner-most apply multiplies variables ALP and CLBFLL3. 

@ The comments here arc useful for humans to understand how the equation is being built 
up: the processing application ignores all comments. 

Example 5. Another example of an output variable based on a calculation element 

This cxccipt is an example of how an output variable (CL) might be defined from previously 

calculated local variables (in this case, CLO. CLBFL. etc.). 
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<1-- Output variables --> 

< 1 -- ——————— 

<variableDef name-"CL" varID="CL" units="nd" sign~"+UP" symbol -"CL"* 
<description> 

Coefficient of lift 

CL = CLO ♦ CLBFUL ♦ CLBFUR ♦ CLBFLL * CLBFLR + 

CLWFL ♦ CLWFR * CLRUD + CLGE ♦ CLLG 

</description> 

<calculation> 

<math> 

<apply^ 0 
<plus/> 

<ci>CL0</ci> 

<ci*CLBPUL</ci > 

<ci >CLBFUR</ci > 

<ci>CLBFLL</ci> © 

«ci >CLBFLR</ci > 

<ci >CLWFLc/ci> 

<ci>CLWFR</ci> 

<ci*CLRUD</ci* 

<Ci>CLGE</ci> 

<ci>CLLG</ci> 

< /apply* 

</math> 

</calculat ion> 

<isOutput/:> © 

</variableDef > 


O Hare apply simply sums the value of these variables, referenced by their varlDs. 

© This ci element refers to the lower’ left body flag lift contribution calculated in the previous 
example (p. 27). 

© Tire i sOutput element signifies to tire processing application that this variable should be 
made visible to models external to this DAVEf unc. 

Example 6. An intermediate variable with a calculation element that uses a DAVE-ML function 
extension to the default MathML-2 function set 

In this cxccrpL wo demonstrate a means to encode a math function, atcw2, that is not available in 
the default MathMI,-2 function set. The atan2 function is used often in C, C++, Java and other 
modeling languages and has been added to the DAVE-ML standard by use of the MathML-2 
c symbol element, specifically provided to allow extension of MathML-2 for cases such as this. 


«l-- .................. — > 

<1 ATAN2 example -->0 

< 1 -- — — — — — > 

cvariableDef name="Wind vector roll angle" varID*"PHI" units-"rad“> 
■^description* 

This encodes the equation PHI = atan2( tan (BETA), sin(ALPHA) ) where atan2 
is the two-argument arc tangent function from the ANSI C standard math 
library. 

</description> 

< calculation* 

<math> 

< apply* 

cesytnbol def initionURL-"http: //daveml .org/function_spaces.html#atan2“ 
encoding ■ "t ext " > © 

atan2 
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</csymbol> 

< apply > 

<tan/ > 

<ci>BETA</ci> © 
< /apply > 

< apply > 

<sin/> 

<ci >ALPHA< /ci > O 
</apply> 

< /apply > 

</nath> 

</calculation> 
</variableDef > 


O This excerpt shows how to calculate wind roll angle, phi. from angle-of-attack and angle- 
oi-sideslip; it comes from the Apollo aerodynamics data book [NAA64J. 

© Ilic csymbol element is provided by Math ML- 2 as a means to extend the function set 
of MathML-2. An extension for atanl is the only function defined at present but others 
may be added to the set in the future. Note the specific URI that uniquely identifies this 
function; it is also the URL (web address ) of the documentation of the interpretation of the 
atanl function. 

© BETA is the varlD of a previously defined variable. 

© ALPHA is the varlD of a previously defined variable. 

6.2.3. The breakpoint set definition element 

The breakpoint set definition element. breakpointDef, is used to define a list of comma- or 
white space-separated values that define the coordinate values along one axis of a gridded linear 
function value table. It contains a mandatory bpID attribute, an optional name and units-of- 
measure attributes, an optional text description element, and the comma- or white space- 
separated list of floating-point values in the bpVals element. Ibis list must be monotonically 
increasing in value. 

breakpointDef s bpID, [name, units] 
description? s 
bpVals : 

{character data of comma- or white space- separated breakpoints} 


breakpointDef attributes: 

bpID 

name 

units 

breakpointDef sub-elements: 

description 

bpVals 


An internal reference that is unique within the file. 

A UNICODE name for the set (may be the same string 
as bp ID). 

The units-of-measurc for the breakpoint values. See 
Section 6.5.6 (p. 56) below. 


An optional text description of the breakpoint set. 

A comma- or white space-separated. monotonically 
increasing list of floating-point values. 
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Example 7. Two breakpointDef examples in a DAVE-ML model excerpt 

As an example, two breakpoint sets arc defined which arc used in the function clement gix'cn 
below (Example 11 (p. 41). Breakpoint sets XMACH1_PTS and DBFL_PTS contain values 
for Mach and lower body flap deflection, respectively, which arc used to look up function values 
in several gridded function tables. One example is given below' in Example 8 (p. 33). 

<i— .......... — -- > 

cl-- ......................... BREAKPOINT SETS ......................... --> 

< I - - ..................... ..» 


cbreakpoi ncDftf n.ime-'mach " bpID-"XMACHl_PTS" unice=*nd H > O 
edeser i pt ion> 

Mach number breakpoints for all aero data tables 
./description 
cbpVals > 

0.3, 0.6, 0.8, 0.9. 0.95, 1.1, 1.2, 1.6, 2.0, 2.S, 3.0, 3.5, 4.0 6 

</bpVals> 

</breakpointDef > 

cbreakpointDet name-^Lower body flap' 1 bpID-"DBFL_PTS" 'units - "dc-q " > © 

cdescription>Lower body flap deflections breakpoints for tablesc/description» 
<bpvals>o., 15., 30., 45., 60.</bpVals» 

</breakpointDef > 


O Ibis breakpointDef element describes a Mach breakpoint set uniquely identified as 
XMACH1_PTS with no associated units of measure. 

@ The breakpoint values are given as a comma- or white space-separated list and must be in 
monotonically increasing numerical order. 

© ibis breakpoint set defines the breakpoints for lower body flap deflection. 

6.2.4. The gridded table definition element 

The griddedTableDef element defines a multi-dimensional table of values corresponding 
with the x'alue of an arbitrary function at each intersection of a set of specified independent 
input values. The coordinates along each dimension are defined in separate breakpointDef 
elements that are referenced within this element by bpRef s, one for each dimension. 

The data contained within the data tabic definition arc a comma- or w'hitc space-separated set 
of floating-point values. This list of values represents a multi-dimensional array w hose size is 
infcitcd from the length of each breakpoint vector. For example, a 2D tabic that is a function of an 
eight-element Mach breakpoint set and a ten-element angle-of-attack breakpoint set is expected 
to contain 80 (8 x 10) comma- or white space-separated values. 

By convention, the breakpointRef s are listed in order such that the last breakpoint set 
v aries most rapidly in the associated data table listing. Sec Section 6.5. 1 (p. 55) below. 

.An optional uncertainty element may be provided that represents the statistical variation 
in the values presented. Sec Section 6.4 (p. 49) for more information about this clement. 

griddedTableDef : [name, gtID, units] 
description? 
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{description of table in character data} 

EITHER 

provenanceRe f ? » provlD 
OR 

provenance? s [provlD] 

author* t name, org, [email] 

contact Info* : [contact In foType , contact Location] 

{text describing contact information} 
creationDate : date {in YYYY-MM-DD format} 
documentRef* s IdocID,] ref ID 
modificationRef* s modID 
description? 
breakpointRefs : 
bpRef+ s bpID 
uncertainty? : effect 

(normalPDF : numSigmas | uniformPDF) 
dataTable 

{character data of comma- or white space- separated table values} 


griddedTableDef attributes: 

gtID An internal reference that is unique within the file. 

name A UNICODE name for the table (may be the same string 

asgtID). 

units The units-of-measure of the table's output signal. See 

Section 6.5.6 (p. 56) below. 


griddedTableDef sub-elcmcnts: 


description 


provenance 


breakpointRefs 


uncertainty 


dataTable 


The optional description element allows the author to 
describe the data container! w ithin this griddedTable. 

The optional provenance element allows the author to 
describe the source and history of the data within this 
griddedTable. Alternatively, a provenanceRef 
reference can be made to a previously defined 
provenance. 

The mandatory breakpointRefs element contains 
separate bpRef elements, each pointing to a separately 
defined breakpointDef . Thus, the independent 
coordinates associated with this function table are defined 
elsewhere and only a reference is given here. The order 
of appearance of the bpRefs is important: see the text 
above. 

This optional element, if present, describes the 
uncertainly of this parameter. See Section 6.4 (p. 49) 
for more information about this element. 

The numeric values of the function at the function vertices 
specified by the breakpoint sets are contained w ithin this 
element, in a single comma- or white spacc-scparatcd 
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list, representing an unraveled multi-dimensional table. 
Parsing this list and storing it in the appropriate array 
representation is up to the implementer. By convention, 
tlie last breakpoint value increases most rapidly. 

Example 8. An excerpt showing an example of a griddedTableDef element 

This nonlinear function table is used by a subsequent function in Example 11 (p. 41) to 
specify' an output value based on two input values: body flap deflection and Mach number. This 
table is defined outside of a function element because this particular function table is used by 
two functions: one for the left-lower body flap and one for the lower-right body flap: thus, their 
actual independent (input) variable values might be different. 


<i — --> • 

<i-- Lower Body Flap Tables (definitions) 

<!-- .................................... --> 


<g ri ddedTabl eDe f name« - CLBFLO'' gt ID-"CLBFLO_table'*> © 

<description> © 

Lower body flap contribution to lift coefficient, 
polynomial constant term 
</ descript ion > 

<provenance> 0 

<author name^ "Bruce Jackson" org="NASA Langley Research Center" 
etna 1 1 »"e .b . jackson®la rc . nasa . gov" / > 

<creationDate date-"2003 -01-31"/> 

<documentRef docID*»"REFOl"/> 

</provenance> 


<breakpointRefs> © 

cbpRef bplD ■ " DBF L_PTS " / > 

<bpRef bpID="XMACHl_PTS"/> 

< /breakpoint Ref s> 

<dataTable> <!-- last breakpoint (XMACH) changes most rapidly © 
<1-- CLBFLO POINTS 
<1-- DBFL - 0.0 --> 

0 . 0 00 00E « 0 0 , 0. 00000E* 00 , O.OOOOOE + OO , O.OOOOOE»OD , 0.00000E»00 , 

0. 00000E* 00 , 0 . 00000E* 00 , 0.00000E+00 , O.OOOOOEtOO , 0.00000E»00 , 
O.OOOOOEoOO , 0. OOOOOE+OO , 0 . 00000E+00 , 


<1-- DBFL - 15.0 

-0.86429E-02 , -0. 1Q256E-01 
-0.86299E-02 , - 0. 53679E- 02 
0.51902E-02 , 0. 38813E-02 
<1-- DBFL - 30.0 

0 . 22251E - 01 , 0 . 26405E- 01 

0. 31321E- 01 , 0. 28996E- 01 
0.10804E-01 , 0. 98493E- 02 
<1-- DBFL - 45.0 


--> 0 

, -0.11189E-Q1 
, 0 . 76757E- 02 
, 0.37366E-02 
— > 

, 0.28 805E-01 
, 0 . 1 9698E - 01 
, 0 . 83719E-02 


, -0 . 12121E-01 , -0 .13520E- 01 , 
, 0. 11300E- 01 , 0 . 62992E- 02 , 


, 0.31206E-01 , 0 . 34806E- 01 , 
, 0. 188Q8E- 01 , 0 . 12755E- 01 , 


. [other points in table] 

</dataTable> 

</ griddedTableDef > 


O Comments are good practice for human readers 

@ name is used for documentation purposes: gtID is intended for automatic wiring 
(autocode) tools. 

© Descriptions make for good practice whenever possible. Here we explain the contents of 
the function represented by the data points. 
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O provenance is tlie story of the origin of the data. 

© These bpRefs are in the same order as the table is wrapped (see text above) and must 
be reflected in the referencing function in the same order. In this excerpt, the referencing 
function must list the independent Var Ref s such that the signal that represents delta 
body flap (DBFL) must precede the reference to the signal that represents Mach number 
(XMACH). 

© The points listed within the dataTable element are given as if the last bpRef varies 
most rapidly. Sec the discussion above. 

© Embedded comments arc a good practice. 

6.2.5. The ungridded table definition element 

The ungriddedTableDef element defines a set of non-oithogonal data points, along with 
their independent values (coordinates), corresponding with the dependent value of an arbitrary 
function. 

A ’non-orthogonal’ data set, as opposed to a gridded or ’orthogonal' data set, means that the 
independent values are not laid out in an orthogonal grid. Ibis form must be used if the dependent 
coordinates in any table dimension cannot be expressed by a single monotonically increasing 
vector. 

See the excerpts below for two instances of ungridded data. 

An optional uncertainty clement may be provided that represents the statistical valuation in 
the values presented. See the section on Statistics below for more infonnation about this element. 


ungriddedTableDef : [utID, name, units] 
description? t 

{description character data} 

EITHER 

provenanceRef ? i provlD 
OR 

provenance? : [provlD] 

author* i name, org, [email] 

contactlnfo* s [contactlnfoType, contact Location] 
{text describing contact information} 
creationDate s date {in YYYY-MM-DD format} 
documentRef • s [doclD,] ref ID 
modi ficationRef * s modID 
description? 
uncertainty? : effect 

(normal PDF •. numSigmas) | (uniformPDF s bounds*) 
dataPoint* s 

{coordinate/ value sets as character data} 


ungriddedTableDef attributes: 

ut ID An internal reference that is unique within the file 

name An optional UNICODE name for the table (may be tlie 

same string as utID). 

units Optional units-of-measure for the table's output signal. 

ungriddedTableDef sub-elements: 
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description 


provenance 


uncertainty 


dataPoint 


The optional description element allows the 

author to describe the data contained within this 
ungriddedTable. 

The optional provenance clement allows the author 
to describe the source and history of the data 
within this ungriddedTable. Alternatively, a 
provenanceRef reference can be made to a 
previously defined provenance. 

This optional element, if present, describes the 
uncertainty of this parameter. Seethe section on Statistics 
below for more information about this element. 

One or more sets of coordinate and output numeric 
values of the function at various locations within its input 
space. This element includes one coordinate for each 
function input variable. Parsing this information into a 
usable interpolative function is up to the implemented By 
convention, the coordinates are listed in the same order 
that they appear in the parent function. 


Example 9. An excerpt show ing an ungriddedTableDef element, encoding the data depicted in 
Figure 2 (p. 36). 

This 2D function table is an example provided bv Dr. Peter Grant of the University of Toronto. 
Such a tabic definition would be used in a subsequent function to describe how r an output 
variable would be defined based on two independent input variables. The function table does 
not indicate w hich input and output variables are represented; this information is supplied by the 
function element later so that a single function table can be reused by multiple functions. 


<ungriddedTableDef name-"CLBASIC as function of flap angle and angle-of- 
ftttack" " CLBA1 faFlap_Table" units=" 

<description> 

CL basic as a function of flap angle and angle-of-attack. Note the alpha 
used in this table is with respect to the wing design plane (in degrees) . 
Flap is in degrees as well. 

< /description* 


<provenance> 

<author name»"Peter Grant* org-*UTIAS*/> O 
<creat ionDat e dat e- *20 06 - 11 - 01 V * 
<documentRef refID«*PRGl" /> 

</provenance> 


<l--For ungridded tables you provide a list of dataPoints- - » © 

<dataPoint> 1.0 -5.00 0.44 <!-- flap, alfawdp, CLB- - ></dataPoint > © 

<dataPoint> 1.0 10. 00 0.95 <!-- flap, alfawdp, CLB--x/dataPoint> 

<dataPoint> 1.0 12.00 1.12 <!-- flap, alfawdp, CLB- - ></dataPoint > 

<dataPoint> 1.0 14.00 1.26 <!-- flap, alfawdp, CLB--x/dataPoint> 

<dataPoint> 1.0 15.00 1.32 <!-- flap, alfawdp, CLB- ->< /dataPoint > 

<dataPoint> 1.0 17.00 1.41 <1-- flap, alfawdp, CLB- - >< /dataPoint > 

<dataPoint> 5.0 -5.00 -0.55 <!-- flap, alfawdp, CLB--></dataPoint> 

<dataPoint> 5.0 0.00 -0.03 <1-- flap, alfawdp, CLB- - ></dataPoint > 

<dataPoint> 5.0 5.00 0.50 <l-- flap, alfawdp, CLB- - x/dataPoint > 
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<dataPoint> 5.0 
<dataPoint> 5.0 
<dataPoint> 5.0 
<dataPoint> 5.0 
<dataPoint> 5.0 
<dataPoint> 5.0 


10.00 1.02 < 1 -- flap, 

12.00 1.23 <1-- flap, 

14.00 1.44 <1-- flap, 

16.00 1.63 <1-- flap, 

17.00 1.70 <1-- flap, 

18.00 1.75 <1-- flap, 


<dataPoint modID= T A'> 10.0 -5.00 -0.40 


dataPoint> O 

<dataPoint> 10.0 14.00 
<dataPoint> 10.0 15.00 
<dataPoint> 10.0 16.00 
<dataPoint> 10.0 17.00 
<dataPoint> 10.0 18.00 


1.57 <1-- flap, 
1.66 <1-- flap, 
1.75 <1-- flap, 
1.80 <1-- flap, 
1.84 <1-- flap, 


< / ungr i ddedTabl eDef > 


alfawdp, CLB- -></dataPoint> 
alfawdp, CLB- -></ dataPoint> 
alfawdp, CLB- -></dataPoint> 
alfawdp, CLB- -></dataPoint> 
alfawdp, CLB- -></dataPoint> 
alfawdp, CLB- -></dataPolnt> 
<1-- flap, alfawdp, CLB--></ 

alfawdp, CLB- -></dataPolnt> 
alfawdp, CLB--x/dataPoint> 
alfawdp, CLB- -></dataPoint> 
alfawdp, CLB- -></dataPoint> 
alfawdp, CLB--x/dataPolnt> 


O Example courtesy of Dr. Peter Grant. U. Toronto 

© Comments are a good idea for human readers 

© For a 2D table such as this one, data points give two columns of independent breakpoint 
values and a third column of function values at those breakpoints. 

© The modID attribute implies this point was edited during modification 'A' of this model, 
as described in the file header information. 



Figure 2. The 21) lift function given in Example 9 (p. 35) 

Example 10. An excerpt from a sample aerodynamics model giving an example of a 3D 
ungr iddedTabl eDef element, encoding the data shown in Figure 3 (p. 38). 

In this example, the dependent coordinates all vary in each dimension. 
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< I ' — ---------------------------- o 

<l-- Three- D Table Definition Example --> 

< J -- — — - > 


cungriddedTableDel name- - yawMomentCoeIficientTablel" units- •nd 1 ' 
ut I D " ya wMoment Coefficient Tab 1 e 1 " > 


<dataPoint> 
<dataPoint > 
<dataPoint > 
<dataPoint > 
cdataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint > 
cdataPoint > 
<dataPoint > 
<dataPoint > 
cdataPoint > 
<dataPoint > 
<dataPoint> 
<dataPoint> 
<dataPoint > 
<dataPoint> 
cdataPoint > 
<dataPoint > 
<dataPoint > 
<dataPoint> 
<dataPoint > 
<dataPoint > 
cdataPoint* 
<dataPoint > 
<dataPoint > 
cdataPoint* 
<dataPoint > 
<dataPoint > 
<dataPoint > 
cdataPoint* 
cdataPoint* 
cdataPoint * 
cdataPoint > 
cdataPoint > 
cdataPoint* 
cdataPoint * 
cdataPoint > 
cdataPoint > 


alpha, 

-1.8330592 

-1.9302179 

-2.1213095 

0.2522004 

0.3368831 

0.2987289 

1.8858257 

1.8031083 

1.7773659 

3.8104785 

4.2631596 

4.0470946 

-1.8882611 

-2.1796091 

-2.2699103 

0.0148579 

-0.1214591 

0.0610233 

1.7593356 

1.9717048 

2.0228263 

4.0567507 

3.6534822 

3.6848003 

-2.3347682 

-2.3060350 

-1.8675176 

0.0004379 

-0.1977035 

-0.1467742 

1.6599338 

2.2719825 

2.0406858 

4.0179983 

4.2863811 

3.9289361 

-2.2809763 

-2.0733070 

-1.7624546 

0.2279962 

-0.2800363 

0.0828562 

1.8262230 

1.7762123 

2.2258599 

3.7892651 

4.0150716 

4.1677953 


beta , 

-5.3490387 

-4.9698462 

-5.0383145 

-4.9587161 

-5.0797159 

-4.9691198 

-5.2077654 

-4.7072954 

-5.0317988 

-5.2982162 

-5.1695257 

-5.2541017 

0.2422452 

0.0542085 

-0.3146657 

0.1095599 

-0.0047960 

0.2029588 

-0.0149007 

-0.0870861 

-0.2962294 

-0.2948622 

0.2163747 

0. 0884533 

5.2288720 

4. 9652745 

5. 0754646 

5.1220145 

4.7462188 

5. 0470092 

4.9352809 

4.8865093 

5.3253471 
5. 0826426 
4.8806558 
5.2246849 
9. 9844584 

9. 9204337 

9. 9153493 

9.8962508 

10.3004593 

9. 9008011 

10.0939436 

10.1556398 

9.8009720 

9.8017197 

9.6815531 

9.8754433 


</ungriddedTableDef > 


delta: 
-4.7258599 
0.2798654 
5.2146443 
-5.2312860 
-0.3370540 
5.2868938 
-4.7313074 
0.0541231 
5.1507477 
-4.7152852 
-0.1343410 
5.0686926 
-5.1959304 
0.2454711 
4.8638859 
-4 . 9639500 
0.2788827 
5.0831767 
-5.0494446 
0.0763833 
5.1777078 
-5.1002243 
0.1369900 
4.8214805 
-4.7193014 
0.2324610 
5.1169942 
-5.2734993 
0.0664495 
5.1806131 
-5.1210532 
0.0315210 
5.2880688 
-4.9597629 
-0.2877697 
4.9758705 
-4.8800790 
0.0241722 
5.1985794 
-4.7811258 
0.1413907 
5.2962722 
-4.6710211 
-0.1307093 
4.6721747 
-4.8026383 
-0.0630955 
5.1776223 


y aw Moment Co ef f --> © 

- 0. 0035064l</dataPoint > 

- 0.0120538c/dataPoint> 

-0. 020708 9</dataPoint> 
-0.000882368c/dataPoint> 

- 0. Oil 1846c/dataPoint> 

- 0. 0208758c /da taPoint> 

- 0. 00219842</dataPoint > 

- 0.0iil726c/dataPoint> 
-0.0208074c/dataPoint> 

- 0. 00225906</dataPoint > 

- 0. 0116563c/dataPoint> 

- 0. 021 5506</data Point > 

0 . 0ll3462c/dataPoint> 

- 0. 000253 915</dataPoint> 
-0.0087543l</dataPoint> 

0 . 0105144</dataPoint> 
-0.000487753</dataPoint> 

- o. 008l6086c/dataPoint > 

0 . 0l06762</dataPoint > 

- 0.000332616</dataPoint> 

- 0. 0093807</dataPoint> 

0 . 010196< /dataPoint > 

0 . 000312733</dataPoint > 
-0.00809437</dataPoint> 

0 . 02453c/dataPoint> 

0 . 0133447c/dataPoint> 

0 . 00556052c/dataPoint > 

0. 02 5 0468c /dataPoint > 

0 . 0124083</dataPoint> 

0 . 00475277c/dataPoint> 

0. 0242646</dataPoint> 

0 . 0125658</dataPoint> 
0.00491779c/dataPoint* 

0 . 0243518c/dataPoint> 

0 . 0128886c/dataPoint> 

0 . 0Q47124l</dataPoint> 

0 . 038695lc/dataPoint> 
0.027546</data Point > 

0 . 0188357</dataPoint> 

0. 0375762</dataPoint> 

0 . 0281 44< /data Point > 

0 . 0179398c/dataPoint* 

0 . 037712c /dataPoint > 

0 . 0278079</dataPoint> 

0 . 01 82 4 4c /dataPoint * 

0 . 0368199c/dataPoint > 

0 . 0252014</dataPoint > 

0 . 0164312c/dataPoint > 


O Example courtesy of Mr. Geoff Brian. DSTO 

@ In this example, columns are labeled with an XML comment for human readers. Actual 
association of each input (alpha, beta and della) and the single output (yawing moment) 
to the respective input and output signals is mechanized in any subsequent function 
definition(s). 
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-0.02 -0.01 0 0.01 0.02 0.03 



Yawing Moment coetnclent 



Figure 3. The 3D function given in the previous example 

6.2.6. The function definition element 

The function element connects breakpoint sets (for gridded tables), independent variables, 
and data tables (gridded or ungridded) to their respective output variable. 


function ; name 
description? ; 

{text description of the function} 

EITHER 

provenanceRef ? ; provID 
OR 

provenance? : [provID] 

author+ name, org, [email] 

contact Info* : [contact Inf oType, contactLocation] 

{text describing contact information} 
creationDate : date {in YYYY-MM-DD format} 
documentRef* : [docID,] ref ID 
modif icationRef * : modID 
description? 

EITHER 

( 

independentVarPts+ ; varlD, [name, units, sign, extrapolate, interpolate] 
{input values as character data} 
dependentVarPts : varlD, [name, units, sign] 

{output values as character data} 

) 

OR 

( 
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independent VarRef* : varlD, [min, max, extrapolate, interpolate] 
dependentVarRef ! varlD 
functionDefn : [name] 

CHOICE OF 
( 

griddedTableRef s gtID 
OR 

griddedTableDef : [name, gtID, units] 
description? 

{text description of table} 

(provenance | provenanceRef ) ? {as described earlier} 
breakpoint Refs 

bpRef* : bpID 
uncertainty? ; effect 

(normalPDF : numSigmas) | (uniformPDF : bounds*) 
dataTable 

{gridded data table as character data} 

OR 

ungriddedTableRef t utID 
OR 

ungriddedTableDef s [name, utID, units] 
description? 

{text description of table} 

(provenance | provenanceRef)? {as described earlier} 
uncertainty? i effect 

(normalPDF j numSigmas) | (uniformPDF i bounds+) 
data Point* 

{coordinate/value sets as character data} 

) 

) 


function attributes: 


name 


function sub-elements: 


description 


provenance 


independentVarPts 


A UNICODE name for the function. 


The optional description element allows the author to 
describe the data contained within this function. 

The optional provenance clement allows the author 
to describe the source and history of the data within 
tli is function. Alternatively, a provenanceRef 
reference can be made to a previously defined 
provenance. 

If the author chooses, she can express a 
linearly interpolated functions by specifying the 
independent (breakpoint) value sets as one or 
more independentVarPts which arc comma- 
or white space-separated, monotonically increasing 
floating-point coordinate values corresponding to 
the dependentVarPts. In the ease of multiple 
dimensions, more than one independentVarPts 
must be specified, one for each dimension. The 
mandatory varlD attribute is used to connect each 
independentVarPts set with an input variable. 
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dependent VarPts 


independentVarRef 


dependent Var Ref 


functionDefn 


griddedTableRef 


ungriddedTableRef 


An optional interpolate attribute specifies the 
preference for using linear, quadratic, or cubic relaxed 
splines for calculating dependent values when the 
independent arguments are in between specified values. 
When not specified, the expectation would be to 
use a linear spline interpolation between points. The 
performance of interpolation of various orders is left up 
to the processing application. See Section 6.3 (p. 46). 

This element goes along with tire previous clement to 
specify a function table. Only one dependentVarPts 
may be specified. If the function is multi-dimensional, 
the convention is the last breakpoint dimension changes 
most rapidly in this comma- or white space-separated list 
of floating-point output values. The mandatory varlD 
attribute is used to connect this table's output to an output 
variable. 

One or more of these elements refers to separately defined 
variableDef s. The order of specification is important 
and must match tire order in which breakpoint sets arc 
specified or the order of coordinates in ungridded table 
coordinate/value sets. 

An optional interpolate attribute specifies the 
preference for using discrete, linear, quadratic, or 
cubic splines for calculating dependent values when 
tire independent arguments are in between specified 
values. When not specified, the default expectation would 
be a linear spline interpolation between points. ITie 
performance of interpolation of various orders is lell up 
to the implemented See Section 6.3 (p. 46). 

A single dependentVarRef must be specified to 
connect the output of this function to a particular 
variableDef. 

This element identifies either a separately specified data 
table definition or specifies a private table, either gridded 
or ungridded. 

If not defining a simple function table, the author 
may use this element to point to a separately specified 
griddedTableDef element. 

If not using a simple function table, the author 
may use this element to point to separately specified 
ungriddedTableDef element. 
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Example 11. An excerpt giving the example of a function which refers to a previously defined 

gr iddedTabl eDe f 

This example ties the input variables DBFLL and XMACH into output variable CLBFLLO 
through a function called CLBFLO_fn, which is represented by the linear interpolation of 
the gridded table previously defined by the CLBFLO_table griddedTableDef (see the 
griddedTableDef example above). 


< i - - —————————— - -> 

<l-- Lower left body flap functions --> 

< 1 -- --> 

^function name- "CLBFLLO" > 

<description> 

Lower left body flap lookup function for lift, polynomial constant term. 

< /descript ion> 

<independentVarRef varID»"DBFLL" min«"Q.O" max="60." ext rapolate-"neither"/' O 
cindependentVarRef varlD**" XMACH” min-"0.3* max=“4.0“ extrapolate- "neither"/ > 
<dependentVarRef varlD- "CLBFLLO "/ > © 

<functionDefn name="CLBFLO_fn"> 

<griddedTableRef gtID-"CLBFLO_table"/> © 

</ functionDefn> 

</ functions 


O The indqiendcnt variables must be given in the order of least-rapidly changing to most- 
rapidly changing values in the previously defined function table. The processing application 
needs to pay attention to the extrapolate attribute, which specifies how to treat a 
variable whose value exceeds the stated limits on input. See Section 6.3 (p. 46). 

@ Tlte dependent variable (identifier! as CLBFLLO) is the output variable for this function. 

CLBFLLO must have been declared previously with a variableDef element. 

© Tltis is a reference to the previously declared griddedTableDef. 

Example 12. A function with an internal tahlc 

In this example, the function CLRUDO returns, in the variable CLRUDO, the value of function 
CLRUD0_f n represented by gridded CLRUDO_table. The inputs to the function are abs_rud 
and XMACH which are used to normalize breakpoint sets DRUD_PTS and XMACH1_PTS 
respectively. The input variables are limited between 0.0 to 30.0 and 0.3 to 4.0, respectively. 

In this case, the use of the CLRUDO string for both the function name attribute and as the varlD 
for the dependent (output) variable reference does not interfere (although they are confusing); 
name is not in the XML namespace. Ihe name attribute is only used for documentation (such 
as a label for a box representing this function). 


<1-- Rudder functions 

< 1 -- ---------------- — > 

<l-- The rudder functions are only used once, so their table 
definitions are internal to the function definition. 

z O 

< function name "CLRUDO" • © 

<description> 
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Rudder contribution to lift coefficient, 
polynomial multiplier for constant term. 

</description> 

<provenance> © 

<author name "Bruce Jackson" org="NASA Langley Research Center" 
email-"© .b . jackson®larc . nasa . gov"/ > 

<creationDate date-"2003 -01 - 31"/> 

<documentRef docID "REF01"/> 

< /provenance > 

<independentVarRef varID-"abs_rud" min-"0.0" max»"30." extrapolate-"neither"/> 
<independentVarRef varID-"XMACH" min-"0.3" max«"4.0* extrapolate-"neither"/ > 
<dependentVarRef varID-"CLRUD0*/> © 


<functionDefn name~"CLRUDO fn"> 


<griddedTableDef name -"CLRUD0_t able" > © 

<br eakpoi nt Ref s > 

<bpRef bpID«"DRUD_PTS"/> 

<bpRef bpID-"XMACHl_PTS"/> 

</breakp*ointRefs> 

cdataTable> <1-- last breakpoint changes most rapidly 


< 1 -- CLRUDO POINTS --> 
<1— RUD - 0.0 

0. 00000E*00 , 0. OOOOOE-OO 
0. 0000QK* 00 , 0 . 00 000E* 00 
0.00000E»00 , 0. 00000E* 00 
<1-- RUD - 15.0 --> 

-0.13646E-01 , 0.26486E-01 
0.75071E-02 , 0 . 53891E- 02 
0 . 00000E* 00 , 0 . 00 000E* 00 
<1-- RUD - 30.0 --> 

-0. 12709E-02 , 0. 52971E- 01 
0. 15014E-01 , 0 . 10778E- 01 
0. 00000E+00 , 0.00000E+00 
</dataTable> 

•c / g r i ddedTabl e > 

</ f unct ionDef n> 


, 0.00000E+00 , 0 . 00000E+00 , O.OOOOOE+OO , 
, 0 . 0 000 QE + 00 , 0. OOOOOEtOO , 0.00000E»00 , 
, 0 . Q00QQE+00 , 


, 0.16977E-01 
, -0.308Q2E-02 
, 0 . 00000E>00 


, -0. 16891E-01 , 0 . 10682E- 01 , 
, -0. 59013E-02 , -0.95733E-02 , 


, 0.33953E-01 , -G. 33782E-01 , 0.21364E-01 , 
, -0 . 61604E-02 , -0 . 11803B-01 , -0 . 19147E-01 , 
, 0 . OOOOOE-f 00 


</function> 


O Tliis comment helps humans understand the reason for an embedded table. 

0 The name attribute is used for documentation purposes, not for internal variable linkage. 
@ The provenance element is required by the AIAA standard [AIAA10]. 

O The varlD attribute is used to link the output of this function with a previously defined 
variable as given in Kxample 3 (p. 27). 

0 This example has an embedded gridded table. 

Example 13. A simple ID function 

At the other end of the spectrum, a simple ID nonlinear function can be defined w ith no reuse, 
as shown below; however, multiple-dimension functions are supported by adding additional 
independentVarPts definitions. 


< function name="CL"> 

<independentVarPts varID-"alpdeg* > © 
-4.0, 0., 4.0, 8.0, 12.0, 16-0 
</ independentVarPts> 
cdependentVarPts varlD "cl*> © 

0.0, 0.2, 0.4, 0.8, 1.0, 1.2 
</dependentVarPts > 

</function> 
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O Breakpoints in angle-of-attack are listed here. 

@ Values of cl arc given, corresponding to tire anglc-of-attack breakpoints given prev iously. 

6.2.7. The checkData element 

Hie checkData clement contains one or more inpuL'output vector pairs (and optionally a 
dump of internal values) for the encoded model to assist in verification and debugging of tire 
implementation. 


checkData 

staticShot* i name, [ref ID] 
descript ion? 

{text description of the static test case} 

(provenance | provenanceRef ) ? {as defined previously} 
checklnput s 
signal + 

signalName 
signalUnits 
signalvalue 
interna lvalues? 
signal ♦ 
varlD 

signal Value 
checkoutputs 
signal + 

signalName 

signalUnits 

signalValue 

tol 


checkData sub-elements: 

staticShot One or more check -case data sets. each 

of which contain mandatory sub-elements 
checklnputs and checkOutputs vectors 
(with required match tolerances), and optional 
provenance, provenanceRef, description 
and internalValues sub-elements. 

Example 14. Cheek-case data set excerpl 

A DAVE-ML file excerpt specifying a check-case data set example for a simple model 


<checkData> 

<staticShot nam«- B Nominal" reflD-’NOTEl ■> O 

<description»An example static check of a simple DAVE-ML model</description> 
<checklnputs> © 

<signal> © 

<signalName>trueAirspeed</signalNam6> 

<signalUnits>f_s</signalUni ts> 

<signa 1 Values 300 . 000< /signal Value> 

</signal> 

<signal> 

■;signalName>angleOfAttack-;/signalNamep- 

<signalUnits>deg</signalUnits> 

<signaivalue> 5 . 000</signalValue> 
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</signal> 


(similar input signals omitted) 


<signal> 

<signalName>delta elevator* /signalName> 
<signalUnits>deg</signalUnits> 

<signalValue> 0 . 000</signalValue> 

</signal> 

</checklnputs> 

<checkOutputs> 0 
<signal> © 

<signalName>CX</signalName> 
<signalUnits>nd</signalUnits> 
<signalValue>-0. 004 000 000 00 000</signal Value > 
<tol>0. 000001</tol> 

</eignal> 


. (similar output signals omitted) 

< /checkout put s > 

</staticShot> 

<staticShot name "Positive pitch rate" > 0 
<chec)clnputs> 

(similar input and output signal information omitted) 

</checkOutputs> 

</staticShot> 

<staticShot name "Positive elevator"> 

<checklnputs> 

(similar input and output signal information omitted) 

</checkOutputs> 

</staticShot> 

</checkData> 


O 'ITiis first check-case refers to a note given in the file header; this is useful to document the 
source of the check-case values. 

© The checklnputs clement defines the input variable values, by variable name, as well 
as units (so they can be verified). 

© Multiple signal elements are usually given; taken together, these scalar signalss 
represent the check-case input "vector." 

Q The checkOutputs element defines output variable values that should result from the 
specified input values. 

@ Note the included tolerance value, indicating the absolute value tolerance within which the 
output values must match the check-case data values. 

© Multiple check-cases may be specified; this one differs from the previous check-case due 
to an increase in the pitching-rate input. 

Example 15. A second checkData example with internal values 

'ITiis example shows another check-case; this one includes intermediate values as an aide to 

debugging a new implementation. 

<checkData> 

«( provenance j provenanceRef )?> 

<scaticShor name- -Skewed inpuce"> 
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<descriptlon> 

Another example static check? this one includes all the internal, intermediate 
calculations 

to assist in debugging the implementation. 

</description> 

<ch«cklnputs> 

<signal> 

<signalName>trueAirspeed</signalName> 

<signalUhits>f_s</signalUnits»\ 
csignalValue> 300 . 000c/signalValue> 

</signal> 

<signal> 

csignalName>angleOfAttack</signalName> 

<signalUnits>deg</signalUnits> 

<signalValue> 16 .200</signalValue> 

< /signal > 


(similar input values omitted) 


<signal> 

<signalName>bodyPositionOfCmWrtMrc</signalName> 
<signalUnits>f racMAC</signalUnits> 

<signalValue> 0 . l23</signalValue> 

</signal> 

</checkInputs> 

<internalValues> O 
<signal> 

<varID>vt</varID> 

<signalValue>300. 0</signalValue> 

</signal> 

<signal> 

<varID>alpha</varID> 

<signalValue>l6.2</signalValue> 

< /signal > 


. (similar internal values omitted) 

< / int ernal Val ues > 

<checkOutputs > 

<signal> 

<signalName>aeroBodyForceCoef tici ent_X</signalName> 
<signalValue> 0. 04794994533333</signalValue> 
<signalUnits>ndc/signalUnits> 

<tol> 0 . 000001</tol> 

</signal> 

<signal> 

< signal Name>aeroBodyForceCoef ficient_Z</slgnalName> 
<signalValue>-0. 7293 4852554344 </signalValue> 
<signalUnits>nd</signalUnit s> 

<tol>0. 00000l</tol> 

</signal> 

<signal> 

<signalName>aeroBodyMomentCoef ficient_Pitch</signalName> 
<signalValue>-0.10638585796503</signalValue> 

-;signalUnit s >nd< / signalUnit s ^ 

<tol>0. 000001</tol> 

</signal> 

</checkOutputs> 

</staticShot> 

</checkData> 


O The internalValues element, if present, usually is a list of all model-defined internal 
variable values. This is normally not required for a model exchange, but such information 
is very useful to aide in debugging the implementation by the recipient. 
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6.3. Function interpolation/extrapolation 

It is possible to specify the method of interpolation to be used for nonlinear function tables by use 
of the interpolate attribute of the independentVarPts and independentVarRef 
elements. This attribute, combined with the extrapolate flag, provides several differ ent ways 
of realizing the intermediate values of the function when not at one of the specified intersections 
of independent values. 

Possible values for the interpolate attribute are: 

discrete Output uses value associated with nearest breakpoint 

floor Output uses value associated with next (numerically 

higher) breakpoint 

ceiling Output uses value associated with last (numerically 

lower) breakpoint 

1 inear (default) Output is linearly interpolated between breakpoints 

quadraticSpline Output follows a quadratic spline fit through values 

associated with two nearby breakpoints 

cubi cSpl ine Output follows a cubic spline fit through values associated 

with three nearby breakpoints 

Possible values for the extrapolate attribute are: 

neither (default) Output is held constant at value associated with closest 

end of breakpoints if the input value is outside the limits 
of the associated breakpoint set 

min Output follows extrapolated values of function if the input 

is below the minimum breakpoint value 

max Output follows extrapolated values of function if the input 

is above maximum breakpoint value 

both Output follows extrapolated values of function if the input 

is outside the limits of the associated breakpoint set 

Implementation of the specific interpolation algorithm is left up to the implementor. One 
reference is the Wikipedia entry on interpolation [wikiOl], 

The follow ing implementation notes are suggested: 

• An infinite set of quadratic interpolations are possible: it is suggested to use the one that 
minimizes either the dev iation from a linear interpolation or the slope error at any edge. 

• For cubic interpolation, the natural cubic spline (which has a second derivative of zero at each 
end) is recommended when tire extrapolate attribute is none. When the extrapolate 
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attribute is both, a clamped cubic spline that matches the extrapolated slope of the last two 
data points is suggested. 

• For tlie discrete interpolation values (discrete, ceiling, or floor), the value of the 
extrapolate attribute is meaningless. 

For discrete interpolation, 

• discrete implies the change between output values occurs midway between independent 
breakpoint values, as shown in the top plot of Figure 4 (p. 48). 

• ceiling means the output takes on the value of the next-higher dependent variable 
breakpoint as soon as each independent breakpoint value is passed (assuming the input value 
is increasing) as shown in the middle plot of Figure 4 (p. 48). 

• floor means the output retains the value of the last dependent variable breakpoint until the 
next independent breakpoint value is reached ( assuming the input value is increasing) as shown 
in the bottom plot of Figure 4 (p. 48). 

The default value for interpolate is linear. The default value for extrapolate is 

neither. 

Figures 4 (p. 48)and 5 (p. 49)bclow give nine different examples for a ID table whose 

independent values are [ 1, 3, 4, 6, 7.5] with dependent values of [2, 6, 5, 7, 1.5]. 
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3 4 5 

Independent variable 



nterpolate="ceiling" < 

T „ 

> 

1 1 1 1 1 

i i 


i i i i i i i i 

0 1 2 3 4 5 6 7 8 9 

Independent variable 



4 5 

Independent variable 


Figure 4. Example of the three discrete aiumeration values of interpolate attribute of the 

independentVarPts and independentVarRef elementsfor a ID function table. 
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Independent variable 





Independent variable 


Independent variable 



Independent variable 



Figure 5. Examples of the three higher-order interpolation methods showing the effect of the 
interpolate attribute of the independentVarPts and independentVarRef elements for 
a ID function table. 

6.4. Statistical information encoding 

Statistical measures of variation of certain parameters and functions can be embedded in 
a DAVE-ML model in several ways. This information is captured in an uncertainty 
element which can be referenced by variableDef, griddedTableDef and 
ungriddedTableDef elements. For maximum modeling flexibility, it is possible to add 
uncertainty to the independent value arguments to a function or calculation, to the output of a 
function itself, as well as to any output signal. Applying uncertainty at more than one location 
in a calculation change is probably not a good practice, however. 

Details on providing the random values for uncertainties is left to the implementer. 
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Uncertainty in the value of a parameter or function is given in one of two w ays, depending on 
the appropriate probability distribution l'unetion (PDF); as a Gaussian or normal distribution 
(bell cun c) or as a uniform (evenly spread) distribution. One of these distributions is selected 
by including either a normalPDF ora uniformPDF element within the uncertainty 
clement. 

Linear conelation between the randomness of two or more variables or functions can 
be specified. Although the correlation between parameters does not have a dependency 
direction (i.e., the statistical uncertainty of one parameter is specified in terms of tire 
other parameter, therefore the calculation order does not matter), correlation is customarily 
specified as a dependency of one random variable on the value of another random variable. 
correlatesWith identifies variables or functions whose uncertainty 'depends' on the current 
value of this variable or parameter; the correlation sub-element specifies the correlation 
coefficient and identifies the (previously calculated) random variable or function on which the 
con elation depends. 

These correlation sub-elements only apply to normal (Gaussian) probability distribution 
functions. 

F.ach of these distribution description elements contain additional information, as described 
below. 


uncertainty : effect- ['additive' | 'multiplicative' | 'percentage' | 'absolute'] 
EITHER 

normalPDF : numSigmas- [ ' l ' | '2 ' | ' 3 '] 

bounds { scalar value representing the one, two or three sigma bound }: 
(correlatesWith* : varlD | 
correlation* t varlD, corrCoef ) 

OR 

uni formPDF 

bounds { one or two scalar values for abs. or tnin/max bounds } 


uncertainty attributes: 

effect Indicates, by choice of four enumerated values, how the 

uncertainty is modeled: as an additive, multiplicative, or 
percentage variation from the nominal value, or a specific 
number (absolute). 


uncertainty sub-elements: 

normalPDF If present, the uncertainty in the parameter value has a 

probability distribution that is Gaussian (bell-shaped). A 
single parameter representing the additive (* some value), 
percentage (± some %) of variation from the nominal 
value in terms of 1, 2, 3, or more standard deviations 
(sigmas) is specified. Note: multiplicative and absolute 
bounds do not make much sense. 

uniformPDF If present, the uncertainty in the parameter or function 

value lias a uniform likelihood of taking on any value 
between symmetric or asymmetric boundaries, which 
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are specified in terms of additive (either ±x or +x/- 
y), multiplicative, percentage, or absolute variations. If 
absolute, the specified range of values must bracket the 
nominal value. For this element, the bounds sub- 
clement may contain one or two values, in which case the 
boundaries are symmetric or asymmetric. 

Example 16. A variable with absolute uncertainty bounds 

This example shows how to specify that a constant parameter can take on a specified range of 
values with uniform probability distribution. The nominal value of the minimum drag coefficient 
is specified to be 0.005. but when performing parametric variations, it is allow ed to take on values 
between 0.001 and 0.01. 


<DAVEfunc> 

<f il«Header> 


</fileHeader> 

<variableDef name-*CD zero* varID-"CDo* units="nd" initialValue-"Q. Q05"> © 

<descri.pt ion> 

Minimum coefficient of drag with an 
asymmetric uniform uncertainty band 
< /descript ion> 

<isOutput/> 

<uncertainty effect "absolute "> © 

<uniformPDF> 

< bounds > 0 . 0 01 < /bounds > 

<bounds>0. 01 0< /bounds > 

</uni formPDF> 

</uncertainty> 

</variableDef > 

</DAVEfunc> 


O We declare the parameter CDo as having a nominal value of 0.005. 

@ When parametric variations are applied, the value of CDo can vary uniformly between 
0.001 and 0.010. 

Example 17. 10% uncertainty applied to output variable with a uniform distribution 

This example shows how to specify that a variable has a 10% uniformly distributed uncertainty 
band. In this example, the output variable comes from a nonlinear ID function and the uncertainty 
is applied to the output of the table. 

<DAVEfunc> 

<f ileHeader> 


</fileHeader> 

<variableDef name-*angleOf Attack* varID-"Alpha_deg" units- “deg ■> 
<isStdAIAA/> 

</variableDef > 

<variableDef name-*Cm_u" varID-"Cm_u" units-“nd*> 

<description> 
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Coefficient of pitching moment with 10 percent 
symmetric uniform uncertainty band 
< /descript ion> 

<isOutput/> 

<uncertainty ef feet - “percentage" > 0 

<uniformPDF> 

<bounds>lO. 0</bounds> 
c/uniformPDF> 

< /uncertainty> 

</variableDef > 

<breakpointDef bpID=“ALP“> 

<bpVals>0, 5, 10, 15, 20, 25, 30, 35</bpVals> 

< / br eakpoi nt D e f > 

<function name- "Nominal Cm“> 

<descript ion> 

Nominal pitching moment values prior to application 
of uncertainty 
</description> 

< independentVarRef varID-"Alpha_deg“/> 

<dependentVarRef varID-"Cm_u“/> 

<funct ionDefn> © 

<griddedTableDef > 

<breakpointRefs> 

<bpRef bpID-"ALP“/> 

</breakpointRe fs > 

<dataTable> 

5.2, 4.3, 3.1, 1.8, 0.3, 0.1, 0.0, -0.1 
</dataTable> 

</griddedTableDef > 

</functionDefn> 

</function> 

</DAVEfunc> 


O We declare the output variable Cm_u as having the uncertainty of ±10% uniform 
distribution. 

@ Ihis function gives the nominal values of Cm_u as a ID function of angle-of-attack (alpha). 

Example 18. Asymmetric additive uncertainty applied to output variable with uniform distribution 

This example shows how to specify that a variable has an asymmetric, uniformly distributed, 
additive uncertainty band. In this example, the output variable comes from a nonlinear ID 
function and the uncertainty is applied to the output of the table. 

sDAVEfunCs 

<f ileHeader> 


</fileHeader> 

<variableDef name- “angleOf Attack" varID-"Alpha_deg" unlts-"deg“> 
cisStdAIAA/ > 

</variableDef> 

<variableDef name=“Ctn_u" varID="Cm_u" units="nd“> 
description* 

Coefficient of pitching moment with an 
asymmetric uniform uncertainty band 
</description> 

<isOutput/> 

<uncertainty effect -“additive* > O 
<uniformPDF> 

<bounds>-0. 50< /bounds > 

<bounds>0. 00</bounds> 
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</uni formPDF> 

</uncertainty> 

</variableDef > 
cbreakpointDef bpID-^ALP*:* 

<bpVals>0, 5, 10, 15, 20, 25, 30, 35</bpVals> 
</breakpointDef > 

< function name- "Nominal Cm"> 

<description» 

Nominal pitching moment values prior to application 
of uncertainty 
</description> 

<; independentVarRef var ID- "Alpha_deg ■ / > 

<dependentVarRef varID-"Cm_u"/> © 

< f unct ionDefn> 

<griddedTabl eDe f > 

breakpoint Refs > 

bpRef bpID-"ALP“/> 

< /breakpointRe f s > 

<dataTable> 

5.2, 4.3, 3.1, 1.8, 0.3, 0.1, 0.0, -0.1 
</dataTable> 

</griddedTableDef > 

< / f unctionDef n> 

</ f unct ion > 

</DAVEfunc> 


O We declare the output variable Cm_u varies by as much as #0.5 to -t 0.0 about tlie nominal 
value. This delta value is in the same units as the nominal value (i.e. it is not a multiplier 
or percentage but an additive delta to the nominal value which comes from tire ID Cm_u 
function table description). 

0 ibis function gives the nominal values of Cm_u as a ID function of angle-ol'-atlack (alpha). 

Example 19. A II) point-by-point, Gaussian distribution function 

In this example, a Gaussian (normal) distribution function is applied to each point in a ID 

function table, with the 3-sigma value expressed as a multiplier of the nominal value. 

<DAVEfunc> 

<f ileHeader> 


</fileHeader> 

cvariableDef name "angleOf Attack" varID="Alpha_deg" units "deg"> 
<isStdAIAA/> 

</variableDef > 

cvariableDef name "Cmji" varID*"Cm_u" units "nd"> 

< descript ion> 

Coefficient of pitching moment with 10 percent 
symmetric uniform uncertainty band 
< /descript ion> 

<isOutput/> 

</variableDef > 
breakpointDef bpID-"ALP*> 

bpVals>0, 5, 10, 15, 20, 25, 30, 35c/bpVals> 

</breakpoi ntDef > 
efunction name- "Uncertain Cm"> 

<independentVarRef varID-"Alpha_deg"/> 

<dependentVarRef varID-"Cm_u"/> 

<functionDefn> 

<griddedTableDef > 
breakpoint Ref s> 
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cbpRef bpID«"ALP"/> 

< /breakpoint!*© f s > 

cuncertainty ef fect-"multiplicative“ O 

< normal PDF numSigmasu‘'3"> © 

<bounds > 

<dataTable> © 

0.10, 0.0$, 0.06, 0.05, 0.05, 0.06, 0.07, 0.12 
</dataTable> 

< /bounds > 

</normalPDF> 

< /uncertainty > 

<dataTable> O 

5.2, 4.3, 3.1, l.a, 0.3, 0.1, 0.0, -0.1 
</dataTable> 

< / g r l ddedTabl «De f > 

</ f unct ionDef n> 

</£unction> 

</DAVEfunc> 


O This declares the statistical uncertainty bounds of the Cm_u dependent variable will be 
expressed as a multiplication of the nominal value. 

Q This declares that the probability distribution is a normal distribution and the bounds 
represent 3-sigma (99.7%) confidence bounds. 

© This table lists three-sigma bounds of each point of the Cm_u function as a table. The 
tabic must have the same dimensions and independent variable arguments as the nominal 
function; it is in effect an overlay to the nominal function table, but the values represent 
the bounds as multiples of the nominal tunction value. 

O This table defines the nominal values of the function; these values will be used if the 
random variable associated with the uncertainty of this function is zero or undefined by 
the application. 

Kxample 20. Two nonlinear functions with correlated uncertainty 

In this example, uncertainty in pitching-moment coefficient varies in direct correlation with lift 

coefficient uncertainty. 


<DAVE£unc> 

<fileHeader> . . . «/fileHeader> 

<variableDef name- "angleof Attack* varID-"Alpha_deg" units-"deg*> 

■cisStdAIAA/ > 

</variableDef > 

<variableDef name "CL_u" varlD "CL_u" units "nd"» 

<doscription> Coefficient of lift with a symmetric Gaussian uncertainty 
of 20%: correlates with Cm uncertainty. < /descript ion> 
uncertainty effect -"multiplicative 1 ^ O 

<nortnalPDP numSigmas-"3 "> 

< bound s > 0 . 2 0 < /bounds > 
ccorrelatesWith varID*’'Cm_u"/ > © 

< /normal PD F> 

</uncertainty> 

</variableDef > 

<variableDef name»*Cm_u" varID-' r Cm_u" units- "nd"> 

<description> Coefficient of pitching moment with a symmetric Gaussian 
uncertainty 

distribution of 30%; correlates directly with lift uncertainty. </ 

description> 

<isOutput/> 

<uncertainty effect -"percentage" > © 
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<normalPDF numSigmas-"3 "> 

<bounds > 3 0< /bounds > 

<corr«lation varID-"CL_u" corrCoef-"l . 0"/> 0 

</normalPDF> 

< /uncart ainty> 

</variableDef > 

<breakpointD«f bpID-"ALP*> 

<bpVals>0, 5, 10, 15, 20, 25, 30, 35</bpVals» 

< /breakpoint Def > 

< function name~ "Nominal CL"> 

<descript ion> Nominal lift coefficient values prior to uncertainty </ 
description 

< independent varRef varID-"Alpha_deg"/> 

<dependentVarRef varID-"CL_u"/> 

< funct ionDefn> 

<g r iddedTabl eDe f > 

<breakpointRefs><bpRef bpID-"ALP' , /x/breakpointRefs> 

<dataTable> 0.0, 0.1, 0.2, 0.3, 0.4, 0.45, 0.5, 0.45 </dataTable> 
</griddedTableDef v 
</functionDefn> 

</ funct ion> 

< funct ion name- "Nominal Cm"> 

■c description Nominal pitching moment values prior to uncertainty </ 
descript ion > 

<independentVarRef varID-"Alpha_deg"/> 

<dependentVarRef varID="Cm_u"/> 

< funct ionDef n> 

<gr iddedTabl eDe f > 

cbreakpointRefsxbpRef bpID="ALP"/x/breakpointRef s> 

<dataTable> 5.2, 4.3, 3.1, 1.8, 0.3, 0.1, 0.0, -0.1 </dataTable> 
</griddedTableDef > 

</ funct ionDef n> 

</ funct ion > 

</DAVEfunc> 


O Liil. coefficient has a nominal value that varies with anglc-of-attack according to a nonlinear 
ID table (given in the "Nominal CL" table defined in this example). When performing 
parametric variations. CL_u can take on a multiplicative variation of up to 20% (3-sigma) 
with a Gaussian distribution. 

© This element indicates that the variation of lift coefficient correlates directly with the 
variation in pitching moment coefficient. 

© Pitching-moment coefficient has a nominal value that varies as a function of angle-of- 
attack, according to a nonlinear ID table (given in the "Nominal Cm" table defined in this 
example). When performing parametric variations. Cm_u can take on a 30% variation (3- 
sigma) w ith a Gaussian distribution. 

© This clement indicates that the variation of pitching moment correlates directly with the 
variation in lift coefficient. 

6.5. Additional DAVE-ML conventions 

To facilitate the interpretation of DAVE-ML packages, the follow ing conventions are proposed. 

Failure to follow any of these conventions should be noted prominently in the data files and any 

cover documentation. 

6.5.1. Ordering of points 

In listing data points in multi-dimensional table definitions, the sequence should be such that the 

last dimension changes most rapidly. In other words, a table that is a function of f(ci,b,c) should 
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list the value for f(l,l,l), tlien f(l,l,2), etc. This may be different than, say, a Fortran DATA, 
Matlab® script or C++ initialization statement; the responsibility for mapping the data in the 
correct sequence in the model realization is left up to the implementer 

Figure 6 (p. 56) below shows how a 3D table is represented as an unraveled list of points. 



<dataTable> 

1, 2, 3, 4, 5, 6, 27 

</dataTable> 


Figure 6. An unraveled list compared to tile original 30 table 

6.5.2. Locus of action of moments 

It is recommended that all force and moments be considered to act around a defined reference 
point, given in aircraft coordinates. It is further recommended that all subsystem models 
(aerodynamic, propulsive, alighting gear) provide total forces and moments about this reference 
point and leave tire transfer of moments to the center of mass to the equations of motion. 

6.5.3. Decomposition of flight dynamics subsystems 

It is recommended that a vehicle's flight dynamics reactions be modeled, at least at the highest 
level, as aerodynamic, propulsive, and landing/an esling/laimch gear models. This is common 
practice in most aircraft simulation environments familiar to the authors. 

6.5.4. Date format in DAVE-ML 

The recommended way of representing dates in DAVE-ML documentation, especially date 
attributes and creation date elements, is numerically in the order YYYY-MM-DD. Thus, July 
1 5, 2003 is given as 2003-07-1 5. This formatting convention conforms to the ISO-8601 standard 
for representing dates. [ISO8601] 

6.5.5. Common sign convention notation 

A convention for uidicatmg positive sign conventions for measurements is included in Annex A 
of the <lru ft AIAA Flight Dynamics Model Excliange Standard [A1AA10], These acronyms, if 
applicable, should be used whenever possible to enhance communications. 

6.5.6. Units-of-measure abbreviation 

Each variable definition includes a mandatory units attribute. This attribute gives tlie units-of- 
measure for tlie signal represented by the variable and either 'nd' (for non-dimensional) or blank 
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if the signal is a dimensionless quantity or flag. In addition, the use of 'fracf to indicate a fraction 
(0-1) or 'pet' to indicate a percentage (0-100 or more) is encouraged. 

Informally, this attribute can take on any reasonable abbreviation for a set of units that might be 
understandable by the intended audience, in either set of units (English or ISO). For greater re- 
usability, it is recommended that the set of measurements listed in the A1AA Flight Dynamics 
Model Exchange Standard [AIAA10] (of which this document is a part) be used. The Standard 
recommends how to encode powers of units (f s2 for ft sec 2, for example). 

6.5.7. Internal identifiers 

Identifiers are used throughout DAVE-ML to connect signals, functions, modification records 
and reference documents with each other, c.g., utID, gtID, bpID, refID. etc. These 
identifiers are character strings that must comply with the XML specification for Names [W3C- 
XML]. They must start with a character or underbar, may not start with "xml" or "XML," and 
may not contain colons, among other restrictions. In addition, the identifiers must be unique 
within a single DAVE-ML file. See the XML (W3C-XML) (p. 132) for more information 
regarding valid XML Names. 

6.5.8. DAVE-ML Namespace 

The XML standard allows for namespace domains, in which element names belong to either 
the empty (null) namespace or to a namespace that belongs to a particular XML grammar. 
Namespaces are identified by a uniform resource identifier (L'RI) that is fashioned, similar to a 
URL, in order that uniqueness is guaranteed. 

The DAVE-ML namespace should be defined in the top-level element as follows: 

<DAVEfunc xmlns»"http: //daveml .org/20l0/DAVEML"> 

This will allow DAVE-ML models to be embedded in other XML documents w ilhout confusion. 
Note that this general URI is not a URL; HTTP queries at that address may not lead to any useful 
information. 

The reference element can include two elements that belong to the World-Wide Web 
Consortium (\V3C)'s XLINK protocol [W3C- XI .INK]; they arc defined with an xlink: 
prefix which actually refers to tire namespace uniquely defined with the http:// 
www.w3c.org/1999/xlink URI. If external links to documents will be included in a 
DAVE-ML document the top-level element (currently reference) must include a namespace 
declaration (which looks like, but technically is not. an attribute): 

< ref erence xml ns : xl i nk= "http : / /www . w3 . org/ 1 999/xl 1 nk" > 


Similarly, the MalhML-2 elements are normally defined in a MathML namespace, so any 
calculation defined using MathML-2 notation should be conducted inside the MathML 
namespace: 


<math xml ns- "https //www. w3 .org/ 1998/Math/ MathML" > 
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6.6. Planned major elements 

Additional major elements may be defined to support tire goal of rapid exchange of simulation 
models, including 

• Support for vector and matrix variables and math operations. 

• Subsystem models, to support hierarchical decomposition and problem abstraction. 

• State variables, both discrete and continuous, to support dynamic models. 

• Dynamic (time-history) data file format, to allow for validation check-cases for dynamic 
models 
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7. Further information 

Further information, background, and the latest DTD and example models of some aircraft data 
packages can be found at the DAVE-ML web site: http://davcml.org 
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8. Element references and descriptions 

This section lists the XML tags, or elements, that make up the DAVE-ML grammar. They are 
listed alphabetically in two sub-sections; tire first is a short description of each element; the 
second sub-section gives details on the element, attributes, and sub-elements. 


8.1. Alphabetical list of elements 


address 

Street address or other contact information of an author 
[Deprecated.] 

author 

Gives name and contact information for originating party 
of the associated data 

bounds 

Describes limits or standard deviations of statistical 
uncertainties 

bpRef 

Reference to a breakpoint definition 

bpVals 

String of while space- or comma-separated values of 
breakpoints 

breakpointDef 

Defines breakpoint sets to be used in model 

breakpoint Ref s 

A list of breakpoint reference (bpRefs) 

calculation 

Used to delimit a Math MI, v2 calculation 

checkData 

Gives verification data for encoded model 

checklnputs 

Lists input values for check case 

checkOutputs 

I .ists output values for chock case 

conf idenceBound 

Defines the confidence in a function [Deprecated] 

contactlnfo 

Provides multiple contact information associated with an 
author or agency 

correlatesWith 

Identifies other functions or variables whose uncertainty 
correlates with our random value 

correlation 

Indicates the linear correlation of this function's or 
variable's randomness with a previously computed 
random variable 

creationDate 

Gives date of creation of entity 

dataPoint 

Defines each point of an ungridded table 

dataTable 

Lists the values of a table of function or uncertainty data 

DAVEfunc 

Root level element 
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dependentVarPts 

dependentVarRef 

description 

documentRef 

extraDocRef 

f ileCreationDate 
f ileHeader 
f ileVersion 
function 

functionCreationDate 
f unctionDefn 

griddedTable 

griddedTableDef 
griddedTableRef 
independentVarPts 
i nde penden t Va r Re f 
internalValues 

isControl 

isDisturbance 

islnput 

isOutput 

isState 

isStateDeriv 

isStdAIAA 


DAVE-ML 2 

Defines output breakpoint values 

Identifies the signal to be associated with the output of a 
function 

Verbal description of an entity 

Reference to an external document 

Allow s multiple documents to be associated with a single 
modification event 

Gives date of creation of entity [Deprecated] 

States source and puiposc of file 

Indicates the version of the document 

Defines a function by combining independent variables, 
breakpoints, and tables 

Date of creation of a function table [Deprecated] 

Defines a function by associating a table with other 
information 

Definition of a gridded table; associates breakpoint data 
with table data [Deprecated] 

Defines an orthogonally gridded tabic of data points 

Reference to a gridded table definition 

Simple definition of independent breakpoints 

References a predefined signal as an input to a function 

A dump of internal model values for debugging check- 
cases 

Flag to identify a model control parameter 

Flag to identify a model disturbance input 

Flag to identify' a model input variable 

Flag to identify' non-obvious output signals from model 

l'lag to identify a state variable within a dynamic model 

Flag to identify a state derivative within a dynamic model 

Flag to identify' standard AIAA simulation variable 
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modif icationRecord 

modif icationRef 
normal PDF 
provenance 
provenance Re f 

reference 

signal 

signallD 

signalName 

signalUnits 

signalValue 

staticShot 

tol 

uncertainty 

ungriddedTable 

ungriddedTableDef 

ungr iddedTabl eRe f 

uniformPDF 

variableDef 

variableRef 

varlD 


To associate a reference single letter with a modification 
event 

Reference to associated modification information 

Defines a normal (Gaussian) probability density function 

Describes origin or history of the associated information 

References a previously defined data provenance 
description 

Describes an external document 

Documents an internal DAVE-ML signal (value, units, 
etc.) 

Gives the internal identifier of a varDef [Deprecated] 

Gives the external name of an input or output signal 

Gives the unit-ol-measure of an input or output variable 

Gives the value of a check-case signal/variable 

Used to check the validity of the model once instantiated 
by the receiving facility or tool. 

Specifics tire tolerance of value matching for model 
verification 

Describes statistical uncertainty' bounds and any 
correlations for a parameter or function table. 

Definition of an ungridded set of function data 
[Deprecated] 

Defines a tabic of data, each with independent coordinates 
Reference to an ungridded table 

Defines a uniform (constant) probability density function 
Defines signals used in DAVE-ML model 
Reference to a variable definition 
Gives tlie internal identifier of a varDef 


8.2. Element descriptions 

Ibis section lists each element in detail, giving the name, content model, attributes, possible 
parent elcmenLs, allowable children elements, and any future plans for the element (such as 
deprecation). 
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address 


address — Street address or other eontact information of an author [Deprecated.] 

Content model 

address : 

(# PCDATA) 


Attributes 

NONE 

Possible parents 

author 

Allowable children 

NONE 

Future plans for this element 

This element has been subsumed by the contactlnfo element below. 
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au thor 


author — Gives name and contact information for originating party of the associated data 

Content model 

author : name, org, [xns] , [email] 

(address* | contactlnfo*) 


Attributes 

name The name of the author or last modifier of the associated element's data, 

org The author’s organization. 

xns (optional) (deprecated) The extensible Name Service identifier for the author, 

email (optional) (deprecated) The e-mail address for the primary author. 

Description 

author includes alternate means of identifying author using XNS or normal c-mail/addrcss. The 
address sub-element is to be replaced with the more complete contactlnfo sub-element. 

Possible parents 

f ileHeader 

modif icationRecord 

provenance 

Allowable children 

address 

contactlnfo 

Future plans for this element 

Both the xns and email attr ibutes are deprecated and will be removed. XNS was a proposed 
Internet technology (extensible Name Service) to reduce spam that didn't catch on. It is replaced 
with the 'inamc' sub-clcmcnt as a single means to identify an individual or corporation in lieu of 
typical (and quickly dated) e-mail, phone, or address information. The address element itself is 
deprecated and should be replaced with the contactlnfo clement 
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bounds 


bounds — Describes limits or standard deviations of statistical uncertainties 

Content model 

bounds : 

(# PCDATA | dataTable | variableDef | variableRef ) * 


Attributes 

NONE 

Description 

Ibis element contains some description of the statistical limits to the values the citing parameter 
element might take on. This can be in the form of a scalar value, a private dataTable, or a 
variablcRcf. In the more common instance, this element will either be a scalar constant value 
or a simple table whose dimensions must match the parent nominal function table and whose 
independent variables are identical to the nominal table. It is also possible that this limit be 
determined by an independent variable, either previously defined or defined in-line with this 
element. It does not make sense to have a dataTable cited if this bounds element is associated 
with anything other than an identically shaped function table. 

Possible parents 

normal PDF 
uniformPDF 

Allowable children 

dataTable 

variableDef 

variableRef 
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bp Ref 


bpRcf — Reference to a breakpoint definition 

Content model 

bpRef s bp ID 
EMPTY 


Attributes 

bpID The internal identifier for a breakpoint set definition. 

Description 

ITic bpRcf element provides references to a previously-defined breakpoint set so breakpoints can 
be defined separately from, and reused by. several data tables. 

Possible parents 

breakpointRef s 

Allowable children 

NONE 
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bp Vais — String of white space- or comma-separated values of breakpoints 

Content model 

bpVals : 

(f PCDATA) 


Attributes 

NONE 

Description 

bpVals is a set of breakpoints (i.e.. a set of independent variable values associated with one 
dimension of a gridded table of data). An example would be the Mach or angle-of-attack values 
that define the coordinates of each data point in a 2D coefficient value table. 

Possible parents 

breakpointDef 

Allowable children 

NONE 
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breakpointDef — Defines breakpoint sets to be used in model 

Content model 

breakpointDef s [name) , bpID, (units] 
description? 
bpVals 


Attributes 

name (optional) The name of the breakpoint set. 

bpID Hie internal identifier for the breakpoint set. 

units (optional) The units of measure for the breakpoint set. 

Description 

A breakpointDef lists gridded table breakpoints. Since these are separate from function data they 
may be reused. 

Possible parents 

DAVEfunc 

Allowable children 

description 

bpVals 
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breaJcpointRef s 

breakpointRofs — A list of breakpoint reference (bpRefs) 

Content model 

breakpointRefs : 
bpRe f ♦ 


Attributes 

NONE 

Description 

'ITic brcakpointRcfs clcmcnLs tic the independent variable names for the function to specific 
breakpoint values defined earlier. 

Possible parents 

griddedTableDef 

griddedTable 

Allowable children 

bpRef 
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calculation 

calculation — Used to delimit a NlathML v2 calculation 

Content model 

calculation : 

math (p. 15) 


Attributes 

NONE 

Description 

llic calculation element is MathML 2 content markup deseribing how the signal is caleulated. 
The calculation may include both constants and variables; other variables are included by using 
their varlD string in a MathML content identifier (ci) element. 

Possible parents 

variableDef 

Allowable children 

math (p. 15) 
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chcckData — Gives verification data for encoded model 

Content model 

checkData : 

(provenance | provenanceRef)? 
staticShot ♦ 


Attributes 

NONE 

Description 

This lop-level element is the place-holder for verification data of various forms for the encoded 
model. It will include static check cases, trim shots, and dynamic check case information. The 
provenance sub-element is now deprecated and has been moved to individual staticShots: it is 
allowed here for backwards compatibility. 

Possible parents 

DAVEfunc 

Allowable children 

provenance 

provenanceRef 

staticShot 
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checklnputs 

checklnpuls — Lists input values for check case 

Content model 

checklnputs : 
signal* 

Attributes 

NONE 

Description 

Specifies the contents of the input vector for the given check case. 

Possible parents 

staticShot 

Allowable children 

signal 
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checkOutputs 

chcckOutpuls — Lists output values lor check ease 

Content model 

checJcOutput s ! 
signal ♦ 


Attributes 

NONE 

Description 

Specifies the contents of the output vector for the given check case. 

Possible parents 

staticShot 

Allowable children 

signal 
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oonf idenceBound 

confidenceBound — Defines the confidence in a function [Deprecated] 

Content model 

conf idenceBound : value 

EMPTY 


Attributes 

value Percent confidence (like 95%) in the function. 

Description 

ITic confidcnccBound element is used to declare the confidence interval associated with the data 
table. This is a place-holder and will be removed in a future version of DAVE-ML. 

Possible parents 

griddedTable 

ungriddedTable 

Allowable children 

NONE 

Future plans for this element 

Deprecated. Used only in deprecated [un]griddedTable elements. Use uncertainty element 
instead. 
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oontactlnfo 

contactlnfo — Provides multiple contact information associated with an author or agency 

Content model 

contactlnfo s [contactlnfoType] , (contact Location] 

(f PCDATA) 

Attributes 

contactlnfoType (optional) Indicates type of information being conveyed 

(enumerated). 

• address 

• phone 

• fax 

• email 

• iname 

• web 

contactLocation (optional) Indicates which location is identified. Default is 

professional (enumerated). 

• professional 

• personal 

• mobile 


Description 

Used to provide contact information about an author. Use contactlnfoType to differentiate what 
information is being conveyed and contactLocation to denote location of the address. 

Possible parents 

author 

Allowable children 

NONE 
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oorrelatesWith 

correlates With — Identifies other functions or variables whose uncertainty correlates with our 
random value 

Content model 

correlat«sWith i varlD 
EMPTY 


Attributes 

varlD Identifies the variable or function output that will depend on this function's or 
variable's randomness. 


Description 

When present, this element indicates the parent function or variable is correlated with the 
referenced other function or variable in a linear sense. This alerts the application that the random 
number used to calculate this function’s or variable's immediate value will he used to calculate 
another function's or variable's value. 

Possible parents 

normal PDF 

Allowable children 

NONE 
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correlation 

correlation — Indicates the linear correlation of this function's or variable's randomness with a 
previously computed random variable 

Content model 

correlation : varlD, cor r Coe f 

EMPTY 

Attributes 

varlD 
cor r Coe f 


Description 

When present, this element indicates lire parent function or variable is correlated with the 
referenced other function or variable in a linear sense and gives the correlation coefficient for 
determining this function's random value based upon the correlating function(s)'s random value. 

Possible parents 

normal PDF 

Allowable children 

NONE 


Identifies the variable or function output that helps determine the value of this 
random variable or function. 

Indicates the amount of correlation between this variable and the referenced 
variable. The value should be between til and T; 0 indicates no correlation, 
1 1 indicates perfect correlation and # 1 indicates inverse (negative) correlation. 
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creationDate 

creationDate — Gives date of creation of entity 

Content model 

creationDate : date 

EMPTY 


Attributes 

date 'fhe date of creation of the entity, in ISO 8601 (YYYY-MM-DD) format. 

Description 

creationDate is simply a string with a date in it. We follow ISO 8601 and use dates like 
"2004-01-02" to refer to January 2, 2004. 

Possible parents 

f ileHeader 
provenance 

Allowable children 

NONE 


78 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

279 of 
343 


DAVE-ML 2 


dataPoint 


dataPoint — Defines each point of an ungridded table 


Content model 

dataPoint : (rnodlD] 

(f PCDATA) 


Attributes 

modID (optional) The internal identifier for a modification record. 

Description 

ilic dataPoint element is used by ungridded tables to list the values of independent variables that 
are associated with each value of dependent variable. For example: <dataPoint> 0. 1, -4.0, 0.2 <!- 
Mach, alpha. CL -> </dataPoint> <dataPoint> 0. 1, 0.0, 0.6 <!- Mach, alpha CL -> < dataPoint> 
F.ach data point may have associated with it a modification tag to document the genesis of that 
particular point. No requirement on ordering of independent variables is implied. Since this is an 
ungridded table, the interpreting application is required to handle what may be unsorted data. 

Possible parents 

ungr iddedTabl eDe f 
ungriddedTable 

Allowable children 

NONE 
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dataTable 

dataTable — Lists the values of a table of function or uncertainty data 

Content model 

dataTable : 

(fPCDATA) 


Attributes 

NONE 

Description 

The data ! able element is used by gridded tables where the indep. variable values are implied 
by breakpoint sets. Thus, the data embedded between the dataTable element tags Is expected 
to be sorted ASCII values of the gridded table, wherein the last independent v ariable listed in 
the ftinction header varies most rapidly. The table data point values are specified as comma- or 
white space-separated values in conventional floating-point notation (0.93638K-06) in a single 
long sequence as if the table had been unraveled with the last-specified dimension changing most 
rapidly. Line breaks are to be ignored. Comments may be embedded in the table to promote 
[human] readability, with appropriate escaping characters. A dataTable element can also be used 
in an uncertainty element to provide duplicate uncertainty bound values. 

Possible parents 

griddedTableDef 

griddedTable 

bounds 

Allowable children 

NONE 
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DAVEfunc 

DAVEfunc — Root level element 

Content model 

DAVEfunc : xml ns 

f lleHeader 
variableDef ♦ 
breakpointDef * 
griddedTableDef * 
ungriddedTableDef * 
function* 
checkData? 


Attributes 

xmlns This attribute specifies that the default namespace for un-prefixed elements is this 
DTD. 

Description 

Root element is DAVEfunc. composed of a tile header element followed by one or more variable 
definitions and zero or more breakpoint definitions, gridded or ungridded table definitions, and 
function elements. 

Possible parents 

NONE - ROOT ELEMENT 

Allowable children 

f ileHeader 

variableDef 

breakpointDef 

griddedTableDef 

ungriddedTableDef 

function 

checkData 
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dependentVarPts 

dependentVarPts — Defines output breakpoint values 

Content model 

dependentVarPts : varlD, [name] , [units] , [sign] 

(f PCDATA) 


Attributes 

varlD lhe internal identifier of the output signal this table should drive, 
name (optional) The name of the function's dependent variable output signal, 
units (optional) The units of measure for the dependent variable, 
sign (optional ) The sign convention for the dependent variable. 

Description 

A dcpcndcntVarl’ts clement is a simple comma- or white space-delimited list of function values 
and contains a mandatory varlD as well as optional name, units, and sign convention attributes. 
Data points are arranged as single vector with last-specified breakpoint values changing most 
frequently. Note that the number of dependent values must equal the product of the number of 
independent values for this simple, gridded, realization. This element is used for simple functions 
that do not share breakpoint or table values with other functions. 

Possible parents 

function 

Allowable children 

NONE 
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dependentVarRef 

dependent VarRef — Identifies the signal to be associated with the output of a function 

Content model 

dependentVarRef : varlD 

EMPTY 


Attributes 

varlD Ihe internal identifier lor the output signal. 

Description 

A dependentVarRef tics the output of a function to a signal name defined previously in a variable 
definition. 

Possible parents 

function 

Allowable children 

NONE 
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description 

description — Verbal description of an entity 

Content model 

description : 

(#PCDATA) 


Attributes 

NONE 

Description 

ITic description element is a textual description of an entity, llic full UNICODE character set is 
supported by XML but may not be available in all processing applications. 

Possible parents 

f ileHeader 

variableDef 

breakpoint Def 

griddedTableDef 

ungr iddedTabl eDe f 

function 

reference 

modi f i c at ionRecord 

provenance 

staticShot 

Allowable children 

NONE 
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documentRef 

documentRef — Reference to an external document 

Content model 

documentRef : [docID] , refID 

EMPTY 

Attributes 

docID (optional) (deprecated) The internal identifier of a reference definition element. 
refID The internal identifier of a reference definition clement. 

Possible parents 

provenance 

Allowable children 

NONE 

Future plans for this element 

I'he 'docID' attribute is deprecated; it has been renamed 'rellD' to match its use in the 'reference' 
element. This attribute will be removed in a future version of DAVE-ML. 
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extraDocRef 


extraDocRef — Allows multiple documents to be associated with a single modification event 


Content model 

extraDocRef : ref ID 

EMPTY 


Attributes 

ref ID Ihe internal identifier of a reference definition element. 

Description 

A single modification event may have more than one documented reference. This element can 
be used in place of the refID attribute in a modificationRecord to record more than one refIDs, 
pointing to the referenced document. 

Possible parents 

modificationRecord 

Allowable children 

NONE 
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f ileCreationDate 

filcCrcationDatc — Gives date of creation of entity [Deprecated] 

Content model 

f ileCreationDate : date 

EMPTY 


Attributes 

date The date of the file, in ISO 8601 (YYYY-MM-DD) formal. 

Description 

filcCrcationDatc is simply a string with a date in it. We follow ISO 8601 and use dales like 
"2004-01-02" to refer to January' 2, 2004. Its use is now deprecated in favor of the simpler 
creation Date. 

Possible parents 

f ileHeader 

Allowable children 

NONE 

Future plans for this element 

Tlie filcCrcationDatc and functionCreationDatc have been replaced with a new crcationDatc 
multipurpose element. 
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f ileHeader 

filcHcadcr — States source and purpose of file 

Content model 

f ileHeader : [name] 

author* 

( creat ionDat e | f ileCreationDate) 

f i levers ion? 

description? 

reference* 

modi f icat ionRecord* 

provenance* 


Attributes 

name (optional) The name of tile file. 

Description 

The header clement requires at least one author and a creation date; optional content includes 
version indicator, description, references, and modification records. 

Possible parents 

DAVEfunc 

Allowable children 

author 
creationDate 
f ileCreationDate 
f ileVersion 
description 
reference 

modi f icat ionRecord 
provenance 
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f ileVersion 


file Version — Indicates the version of the document 


Content model 

fileVersion : 
(fPCDATA) 


Attributes 

NONE 

Description 

ITiis is a string describing, in some arbitrary text, the version identifier for this function 
description. 

Possible parents 

f ileHeader 

Allowable children 

NONE 
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function 

function — Defines a function by combining independent variables, breakpoints, and tables 

Content model 

function : name 

description? 

(provenance | provenanceRef ) ? 

C 

i ndependent Var Pt s + 
dependent VarPt 8 

) 

OR 

( 

i ndependent Var Re f ♦ 
dependent Var Re f 
functionDefn 

> 

Attributes 

name The name of this function. 

Description 

Each function has optional description, optional provenance, and either a simple input output 

table values or references to more complete ( possible multiple) input, output, and function data 

elements. 

Possible parents 

DAVE f unc 

Allowable children 

description 
provenance 
provenanceRe f 
independentVar Pt s 
dependent Var Pts 
independentVarRef 
dependent VarRef 
functionDefn 
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functionCreationDate 

functionCreationDate — Date of creation of a function table [Deprecated] 

Content model 

functionCreationDate : date 

EMPTY 


Attributes 

date Ihe creation date of the function, in ISO 8601 (YYYY-MM-DD) format. 

Description 

functionCreationDate is simply a string with a date in it. We follow ISO 8601 and use dates 
like "2004-01-02” to refer to January 2, 2004. Its use is now deprecated in favor of the simpler 
creation Date. 

Possible parents 

provenance 

Allowable children 

NONE 

Future plans for this element 

The filcCreationDate and functionCreationDate have been replaced with a new creationDate 
multipurpose element. 
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functionDefn 

functionDefn — Defines a funetionby associating a table with other information 

Content model 

functionDefn : [name] 

(griddedTableRef | griddedTableDef | griddedTable | ungriddedTableRef 
| ungriddedTableDef | ungriddedTable) 

Attributes 

name (optional) The name of this function definition. 

Description 

A functionDefn defines how function is represented in one of two possible ways: gridded (implies 
breakpoints) or ungridded (with explicit independent values for each point). 

Possible parents 

function 

Allowable children 

griddedTableRef 

griddedTableDef 

griddedTable 

ungriddedTableRef 

ungriddedTableDef 

ungriddedTable 
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griddedTable 

griddedTable — Definition of a gridded table; associates breakpoint data with table data 
[Deprecated] 

Content model 

griddedTable s [name] 
breakpointRefs 
conf i dene ©Bound? 
dataTable 


Attributes 

name (optional) Tlie name of the gridded table being defined. 

Possible parents 

functionDefn 

Allowable children 

breakpointRefs 
con f i dene e Bound 
dataTable 

Future plans for this element 

Deprecated. Use griddedi'ableDef instead. 
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griddedTableDef 

griddedTableDef — Defines an orthogonally gridded table of data points 

Content model 

griddedTableDef : [name] , [gtID] , [units] 

description? 

(provenance | provenanceRef ) ? 
breakpoint Refs 
uncertainty? 
dataTable 


Attributes 

name (optional) The name of the gridded table. 

gtID (optional) An internal identifier for the table. Required if table is to bo reused by 

another function or is defined outside of a tunction. 

units (optional) Units of measure for the table values. 

Description 

A griddedTableDef contains points arranged in an orthogonal (but multi-dimensional) array, 
where the independent variables are defined by separate breakpoint vectors. This table definition 
may be specified separately from the actual function declaration; if so. it requires a gtID identifier 
attribute so that it may be used by multiple functions. 

Possible parents 

DAVEfunc 
f unctionDefn 

Allowable children 

description 

provenance 

provenanceRef 

breakpointRefs 

uncertainty 

dataTable 
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griddedTableRef 

griddedTableRef — Reference to a gridded tabic definition 

Content model 

griddedTableRef : gtID 

EMPTY 


Attributes 

gtID The internal identifier of a gridded table definition. 

Possible parents 

f unc t ionDe f n 

Allowable children 

NONE 
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independentVarPts 

independent Varies Simple definition of independent breakpoints 


Content model 


indepsndentVarPts s varlD, [name], [units], [sign], [extrapolate], [interpolate] 
(# PC DATA) 

Attributes 


varlD 

name 

units 

sign 

extrapolate 


The internal identifier of the input signal corresponding to this independent 
variable. 

(optional) The name of the function's independent variable input signal. 

(optional) The units of measure for the independent variable. 

(optional) The sign convention for the independent variable. 

(optional) Extrapolation flags for IV out-of-bounds (default is neither) 
(enumerated). 

• neither 

• min 

• max 


• both 


interpolate (optional) Interpolation flags for independent variable (default is linear) 
(enumerated). 

• discrete 

• floor 

• ceiling 

• linear 

• quadraticSpline 

• cubicSpline 


Description 

An independentVarPts clement is a simple white space- or comma-separated list of breakpoints 
and contains a mandatory varlD identifier as well as optional name, units, and sign convention 
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attributes. An optional extrapolate attribute describes how to extrapolate the output value when 
the input value exceeds specified values (default is 'neither.' meaning the value of the table is held 
constant at the nearest defined value). An optional interpolate attribute indicates how to perform 
the interpolation within the table (supporting discrete, linear, cubic or quadratic splines), 'fhere 
arc three different discrete options: 'discrete' means nearest-neighbor, with an exact mid-point 
value being rounded in the positive direction; ‘ceiling’ means the function takes on the value 
associated with the next (numerically) higher independent breakpoint as soon as the original 
value is exceeded; and 'floor' means the function holds the value associated with each breakpoint 
until the next (numerically) higher breakpoint value is reached by the independent argument. The 
default interpolation attribute value is 'linear.' This element is used for simple functions that do 
not share breakpoint or table values with other functions. 

Possible parents 

function 

Allowable children 

NONE 
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independentVarRef 

independentVarRef References a predefined signal as an input to a function 


Content model 

independentVarRef : varlD, [min] , [max] , [extrapolate] , [interpolate] 

EMPTY 

Attributes 


varlD 

min 

max 

extrapolate 


Tire internal identifier for the input signal. 

(optional) lire allowable lower limit for the input signal. 

(optional ) The allowable upper limit for the input signal. 

(optional) Extrapolation flags for IV out-of-bounds (default is neither) 
(enumerated). 

• neither 

• min 

• max 


• both 


interpolate (optional) Interpolation flags for independent variable (default is linear) 
(enumerated). 

• discrete 

• floor 

• ceiling 

• linear 

• quadraticSpline 

• cubicSpline 


Description 

An independentVarRef more fully describes the input mapping of the function by pointing to 
a separate breakpoint definition element. An optional extrapolate attribute describes how to 
extrapolate the output value when the input value exceeds specified values (default is 'neither,' 
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meaning Ihe value of the table is held constant at the nearest defined value). An optional 
interpolate attribute indicates how to perform the interpolation within the table (supporting 
discrete, linear, cubic or quadratic splines). There arc three different discrete options: ’discrete' 
means nearest-neighbor, with an exact mid-point value being rounded in the positive direction; 
'floor' means the function takes on the value associated with tine next (numerically) higher 
independent breakpoint as soon as original value is exceeded; and 'ceiling' means the function 
holds tile value associated with each breakpoint until the next (numerically) higher breakpoint 
value is reached by the indqiendcnt argument. The default interpolation attribute value is 'linear.' 
This element allows reuse of common breakpoint values for many tables but with possible 
differences in interpolation or extrapolation for each use. 

Possible parents 

function 

Allowable children 

NONE 
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internalValues 

internalValues — A dump of internal model values for debugging eheek-cases 

Content model 

internalValues s 
signal* 


Attributes 

NONE 

Description 

Provides a set of all internal variable v alues to assist in debugging recalcitrant implementations 
of DAVE-ML import tools. 

Possible parents 

staticShot 

Allowable children 

signal 
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isControl 

isControl — Flag lo identify a model eonlrol parameter 

Content model 

isControl : 

EMPTY 


Attributes 

NONE 

Description 

llie presenee of an isControl element indicates that this signal is a simulation control parameter 
used to vary the operation of the model, e.g. the time step size. Such parameters should be ignored 
when performing linear model extraction (for example) and should not significantly modify the 
dynamic behavior of the model. 

Possible parents 

variableDef 

Allowable children 

NONE 
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isDisturbance 

^Disturbance — Flag to identify a model disturbance input 

Content model 

isDisturbance s 
EMPTY 


Attributes 

NONE 

Description 

The presence of an isDisturbance element indicates that this signal is an external disturbance 
input to the model and can be ignored when performing linear model extraction (for example). 
Such parameters should not significantly modify the nominal dynamic behavior of the model. 

Possible parents 

variableDef 

Allowable children 

NONE 
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islnput 


islnput — Flag to identify a model input variable 

Content model 

islnput : 

EMPTY 


Attributes 

NONE 

Description 

Ihe presence of an islnput element indicates that this variable is an input signal to the model. 

Possible parents 

variableDef 

Allowable children 

NONE 
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isOutput 

isOutput — Flag to identify non-obvious output signals from model 

Content model 

isOutput : 

EMPTY 


Attributes 

NONE 

Description 

llie presenec of the isOutput element indicates that this variable should be foreed to be an output, 
even if it is used internally as an input elsewhere. Otherwise, the processing program may assume 
a signal defined with a calculation and used subsequently in the model is only an internal signal. 

Possible parents 

variableDef 

Allowable children 

NONE 
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isState 


isStatc — Flag to identify a state variable within a dynamic model 

Content model 

isState : 

EMPTY 


Attributes 

NONE 

Description 

llie presence of an isStatc element indicates that this variable is one of possibly multiple state 
variables in a dynamic model; this tells the processing entity that this is the output of an integrator 
(for continuous models) or a discretely updated state (for discrete models). 

Possible parents 

variableDef 

Allowable children 

NONE 
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isStateDeriv 

isStateDeriv — Hag to identify a state derivative within a dynamic model 

Content model 

isStateDeriv t 
EMPTY 


Attributes 

NONE 

Description 

Ibe presence of an isStateDeriv element indicates that this variable is one of possibly several 
stale derivative variables in a dynamic model; this tells the processing entity that this is the output 
of an integrator ( for continuous models only). 

Possible parents 

variableDef 

Allowable children 

NONE 


106 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

307 of 
343 


DAVE-ML 2 


isStdAIAA 

isStdAIAA — Flag to identify standard AIAA simulation variable 

Content model 

isStdAIAA t 
EMPTY 


Attributes 

NONE 

Description 

The presence of an isStdAIAA element indicates that this variable is one of the standard AIAA 
variable names which should be recognizable exterior to this module (e.g. AngleOfAttack deg). 
Ibis Hag should assist importing tools in determining when an input or output should match a 
facility-provided signal name without requiring further information. 

Possible parents 

variableDef 

Allowable children 

NONE 
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modif icationRecord 

modificationRccord — To associate a reference single letter with a modification event 

Content model 

modif icationRecord : modID, date, [ref ID) 

author* 
description? 
extraDocRef* 


Attributes 

modID A single letter used to identity all modified data associated with this modification 
record. 

date The date of the modification, in ISO 8601 (YYYY-MM-DD) format. 

ref ID (optional) A reference to a predefined document that describes the reason for this 
modification. 

Description 

A modificationRecord associates a single letter (such as modification "A") with modification 
author(s), address, and any optional external reference documents, in keeping with the AIAA 
draft standard. 

Possible parents 

f ileHeader 

Allowable children 

author 

description 

extraDocRef 
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modif icationRef 

modificationRof — Reference to associated modification information 

Content model 

modif icationRef : tnodlD 

EMPTY 

Attributes 

modID The internal identifier of a modification definition. 

Possible parents 

provenance 

Allowable children 

NONE 
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normal PDF 


normall’DE — Defines a normal (Gaussian) probability density l'unetion 

Content model 

normal PDF : numSignvas 

bounds 

correlatesWith* 

correlation* 


Attributes 

nutnSigmas Indicates how many standard deviations is represented by the uncertainty 
values given later. Integer value > 0. 

Description 

In a normally distributed random variable, a symmetrical distribution of given standard deviation 
is assumed about the nominal value (which is given elsewhere in the parent element). The 
correlatesWith sub-element references other functions or variables that have a linear corr elation 
to the current parameter or function. The correlation sub-element specifies the correlation 
coefficient and references the other function or variable whose random value helps determine 
the value of this parameter. 

Possible parents 

uncertainty 

Allowable children 

bounds 

correlatesWith 

correlation 
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provenance 

provenance — Describes origin or history of the associated information 

Content model 

provenance : [provID] 

author* 

( creat ionDat e | functionCreationDate) 

documentRef* 

modi float ionRe f * 

description? 


Attributes 

provID (optional) This attribute allows the provenance information defined here to be 
cited elsewhere. 


Description 

The provenance element describes the history or source of the model data and includes author, 
date, and zero or more references to documents and modification records. 

Possible parents 

f ileHeader 

variableDef 

griddedTableDef 

ungr iddedTabl eDe f 

function 

checkData 

staticShot 

Allowable children 

author 

creationDate 

functionCreationDate 

documentRef 

modificationRef 

description 
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provenanceRef 

provenanceRef — References a previously defined data provenance description 

Content model 

provenanceRef s provID 
EMPTY 


Attributes 

provID The internal identifier for a previously defined provenance. 

Description 

When the provenance of a set of several data is identical, the first provenance element should he 
given a provID and referenced by later provenanceRef elements. 

Possible parents 

variableDef 

griddedTableDef 

ungriddedTableDef 

function 

checkData 

staticShot 

Allowable children 

NONE 
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reference 

reference — Describes an external document 

Content model 

reference : xmlns:xlink, xlink:type, refID, author, title, [classification], 

[accession] , date, [xlinkthref] 
description? 

Attributes 

xmlns: xlink 

xlink : type 

refID 
author 
title 

classification 
accession 

date 

xlink: href 

Description 

This element gives identifying (citation) information to an external, possibly on-line, reference 
document, including a user-specified author, title, classification, accession number, date and 
URL. 

Possible parents 

f ileHeader 

Allowable children 

description 


The value of this attribute must be "http://www.w3.org/1999Adink". 
If omitted, it should be provided by the parser since it is specified in 
the DTD. 

'ITic value of this attribute must be "simple". If omitted, it should be 
provided by the parser since it is specified in the DTD. 

An internal identifier for this reference definition. 

lhe name of the author of the reference. 

The title of the referenced document. 

(optional) Hie security classification of the document. 

(optional) The accession number (ISBN or organization report 
number) of the document. 

Hie date of the document, in ISO 8601 (YYYY-MM-DD) format, 
(optional ) A URL to an on-line copy of the referenced document. 
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signal 


signal — Documents an internal DAVE-ML signal (value, units, etc.) 

Content model 

signal : 

( 

signalName 

signalUnits 

) 

OR 

( 

(varlD | signallD) 

) 

signal Value 
col? 


Attributes 

NONE 

Description 

This element is used to document the name, ID, value, tolerance, and units of measure for 
check-cases. W hen used with checklnputs or checkOutputs, the signalName sub-element must be 
present (since check cases are viewed from "outside" the model): when used in an intemalValues 
element, the varlD sub-element should be used to identify the signal by its model-unique internal 
reference. When used in a checkOutputs vector, the tol element must be present. Tolerance is 
specified as a maximum absolute difference between the expected and actual value. The signallD 
sub-element is now deprecated in favor of the more consistent varlD. 

Possible parents 

checklnputs 

intemalValues 

checkOutputs 

Allowable children 

signalName 

signalUnits 

varlD 

signallD 

signalValue 

tol 
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signallD 

signallD — Gives the internal identifier of a varDef [Deprecated] 

Content model 

signallD : 

(f PCDATA) 

Attributes 

NONE 

Description 

Used to specify the input or output varlD. Now deprecated; reuse of varlD is best practice. 

Possible parents 

signal 

Allowable children 

NONE 

Future plans for this element 

The signallD clement has been deprecated with 2.0 in favor of the more consistent varlD element 
and will be unsupported in a future release of this specification. 
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signalName 

signalName — Gives the external name of an input or output signal 

Content model 

signalName : 

(f PCDATA) 


Attributes 

NONE 

Description 

Used inside a checkCase element to specify the input or output variable name 

Possible parents 

signal 

Allowable children 

NONE 
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signalUnits 

signalUnits — Gives the unit-ol'-measure of an input or output variable 

Content model 

signalUnits s 
(fPCDATA) 


Attributes 

NONE 

Description 

Used inside a ehcckCasc element to specify the uniLs-of-measure for an input or output variable, 
for verification of proper implementation of a model. 

Possible parents 

signal 

Allowable children 

NONE 
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signalValue 

signalValue — Gives the value of a check-case signal variable 

Content model 

signalValue : 

(f PCDATA) 

Attributes 

NONE 

Description 

Used to give the current value of an internal signal or input output variable, for verification of 
proper implementation of a model. 

Possible parents 

signal 

Allowable children 

NONE 
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staticShot 

staticShot — Used to check the validity of the model once instantiated by the receiving facility 
or tool. 

Content model 

staticShot i name, [ref ID] 
description? 

(provenance | provenanceRef ) ? 
check Inputs 
internalValues? 
checkoutputs 


Attributes 

name 

ref ID (optional) Points to a reference given in the file header. 

Description 

Contains a description of the inputs and outputs, and possibly internal values, of a DAVE-ML 
model in a particular instant of time. 

Possible parents 

checkData 

Allowable children 

description 

provenance 

provenanceRef 

checklnputs 

internalValues 

checkOutputs 


119 


NESC Request No.: 09-00598 


@ 

NASA Engineering and Safety Center 
Technical Assessment Report 

Document #: 

NESC-RP- 

09-00598 

Version: 

1.0 

Title: 

Flight Simulation Model Exchange 

Page #: 

320 of 
343 


DAVE-ML 2 


tol 


lol — Specifics the tolerance of value malehing for model verification 

Content model 

tol j 

(f PCDATA) 


Attributes 

NONE 

Description 

Iliis element specifies the allowable tolerance of error in an output value such that the model 
can be considered verified. It is assumed all uncertainty is removed in performing tire model 
calculations. Tolerance is specified as a maximum absolute difference betw een the expected and 
actual value. 

Possible parents 

signal 

Allowable children 

NONE 
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uncertainty 

uncertainty — Describes statistical uncertainty bounds and any correlations for a parameter or 
function table. 

Content model 

uncertainty j effect 

(normal PDF | unifortnPDF) 


Attributes 

effect Indicates how uncertainty bounds arc interpreted, (enumerated). 

• additive 

• multiplicative 

• percentage 

• absolute 

Description 

Ihe uncertainty element is used in function and parameter definitions to describe statistical 
variance in the possible value of that function or parameter value. Only Gaussian (normal) or 
uniform distributions of continuous random variable distribution functions are supported. 

Possible parents 

variableDef 

griddedTableDef 

ungriddedTableDef 

Allowable children 

normal PDF 
uniformPDF 
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ungriddedTable 

ungridded’ Table — Definition of an ungridded sot of function data [Deprecated] 

Content model 

ungriddedTable : [name] 

conf idenceBound? 
data Point ♦ 


Attributes 

name (optional) The name of the ungridded table being defined. 

Possible parents 

f unctionDefn 

Allowable children 

conf idenceBound 
data Point 

Future plans for this element 


Deprecated. Use ungriddcdTablcDcf instead. 
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ungriddedTableDef 

ungriddedTableDef — Defines a table ol' data, eaeh with independent coordinates 

Content model 

ungriddedTableDef : [name] , [utlD] , [units] 

description? 

(provenance | provenanceRef ) ? 

uncertainty? 

dataPoint+ 


Attributes 

name (optional) The name of the ungridded table. 

utlD (optional) An internal identifier for the table. Required if table is to be reused by 
another function or is defined outside of a Junction. 

units (optional) The units of measure for the table values. 

Description 

An ungridded TableDef contains points that are not in an orthogonal grid pattern; thus, the 
independent variable coordinates arc specified for each dependent variable value. This table 
definition may be specified separately from the actual function declaration; if so, it requires an 
internal utlD identifier attribute so that it may be used by multiple Junctions. 

Possible parents 

DAVEfunc 
f unctionDefn 

Allowable children 

description 

provenance 

provenanceRef 

uncertainty 

dataPoint 
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ungriddedTableRef 

ungriddedTableRef — Reference to an ungridded table 

Content model 

ungriddedTableRef : utID 

EMPTY 


Attributes 

utID The internal identifier of a ungridded table definition. 

Possible parents 

f unc t ionDe f n 

Allowable children 

NONE 
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uniformPDF 

uniformPDF — Defines a uniform (constant) probability density function 

Content model 

uniformPDF : 
bounds ♦ 


Attributes 

NONE 

Description 

In a uniformly distributed random variable, the value of the parameter has equal likelihood of 
assuming any value within the (possibly asymmetric, implied by specifying two) bounds, which 
must bracket the nominal value (which is given elsewhere in the parent element). 

Possible parents 

uncertainty 

Allowable children 

bounds 
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variableDef 

variableDef — Defines signals used in DAVE-ML model 

Content model 

variableDef : name, varlD, units, [.axis System] , [sign], [alias], [symbol], 

[initialValue] 
description? 

(provenance | provenanceRef ) ? 
calculation? 

(islnput | isControl | isDisturbance) ? 

isState? 

isStateDeriv? 

isOutput? 

isStdAIAA? 

uncertainty? 


Attributes 


name 

varlD 

units 

axisSystem 

sign 

alias 

symbol 

initialValue 

Description 


Tile name of the signal being defined. 

An internal identifier for the signal. 

The units of the signal. 

(optional) The axis in which the signal is measured. 

(optional) The sign convention for the signal, if any. 

(optional) Possible alias name (facility specific) for the signal, 
(optional) UNICODE symbol for the signal. 

(optional) An initial and possibly constant numeric value for the signal. 


variableDef elements provide wiring information (i.e., they identify the input and output signals 
used by these function blocks). They also provide MathML content markup to indicate any 
calculation required to arrive at the value of the variable, using other variables as inputs. The 
variable definition can include statistical information regarding the uncertainly of the values 
which it might take on. when measured after any calculation is performed. Information about the 
reason for inclusion or change to this element can be included in an optional provenance sub- 
element. 


Possible parents 

DAVEfunc 

bounds 
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Allowable children 

description 

provenance 

provenanceRe f 

calculation 

is Input 

isControl 

isDisturbance 

isState 

isStateDeriv 

isOutput 

isStdAIAA 

uncertainty 
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variableRef 

variableRef — Reference to a variable definition 

Content model 

variableRef : varlD 

EMPTY 


Attributes 

varlD llie internal identifier of a previous variable definition. 

Possible parents 

bounds 

Allowable children 

NONE 
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varlD 


varlD — Gives the internal identifier of a varDef 

Content model 

varlD ! 

(fPCDATA) 


Attributes 

NONE 

Description 

Used to specify the input or output varlD. Replaces earlier signallD clement. 

Possible parents 

signal 

Allowable children 

NONE 
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A 

'accession' attribute 

of 'reference' element, 113 
'address' element (deprecated) 
as child of 'author' element, 64 
definition, 63 
deprecation. 9 
AIAA 
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web site, 12 
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introduction. 16 
overview, 30 
reuse. 20 
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Brian, Geoffrey. 7, 8, 8, 8, 8, 8. 37, 130 
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as child of 'variablcDcf element. 25, 127 
definition, 70 
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as child of 'DAVEfunc' clement, 20, 81 
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example of 

with internal values, 44 
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definition, 76 
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as child of 'normalPDF element 1 10 
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as child of 'provenance' element 1 1 1 
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as child of 'staticShot' element. 1 19 
as child of 'ungriddcdTableDef clement. 35, 123 
as child of 'variableDef element, 25, 127 
definition, 84 

'docID' attribute (deprecated) 
of 'documentRef element 85 
'documentRef element 

as child of 'provenance' clement 1 1 1 
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example of, 41 
example of simple. 42 
example of with internal table. 41 
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overview, 38 
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'functionDefn' element 

as child of 'function' element 40. 90 
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function table 

dimensionality, 17 
reuse, 17 

Kurtek, Jeremy, 130 
future plans, 58 

G 
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H 
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I 

ID strings. 57 
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as child of 'function' element 39, 90 
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'independent VarRef element 
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'interpolate' atlribule 

of'indepcndcntVarPts' clement, 96 
of 'indcpcndcnlVarRcf element, 98 
overview. 46 
interpolation 

of ungridded data, 20 
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’isDisturbancc' clement 
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definition, 108 
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